Question about engines.h and speeds

[BillSargent]

The idea behind the openness of this game is so that ideas can come in and be discussed.

Wrong. The idea behind 'open' is that everyone can go, take the source and make it a 'better' game by his or her personal standards. <rest of reply deleted due to conerns about politeness>

tell me privately.

[Rubidium]

Arguably almost everyone, of influence at least, who says something can't be done say so because they have actually, privately, tried to change a particular aspect of the game. During that effort they came to the conclusion that it either doesn't work, or it doesn't provide a significant benefit, or it breaks backward compatability in some way.

So, before saying I'm hostile: I'm trying to figure out what how you intend to solve the problems you see. That way we can specifically point to "issues" that need to be solved before one could actually implement your idea, and maybe by specifying the proposed changes you'll find some other reasons why it won't work.

Also... your comparison seems to disregard scale. The Sims (1) has been sold 16 million times (by 2005), whereas the latest OpenTTD has some 200.000 downloads. That's two orders of magnitude difference, so a two order magnitude difference between content on Bananas and in the Sims wouldn't be that surprising.

The Sims 3 store's about page talks about hundreds of items/sets. It should have tens of thousands if its size would be linearly related to its user base, and OpenTTDs user to content ratio. A quick scan of The Sims 2 store (opened 2008) doesn't seem to have anywhere near tens of thousands of items either, and that's even older than bananas. So, does OpenTTD really provide less extra content per user?

Even then, The Sims sells mostly seperate items whereas OpenTTD have whole sets, consisting of dozens if not hundreds of vehicles, industries, houses, etc.


Finally, with all (computer) programming you'll see that over time things get abstracted more, and a higher level language is introduced bringing it brought closer to the end user but less powerful. NFO is the most powerfull for NewGRFs, then comes NML (compare it to C), after that come things like GRFWizard/GRFMaker which provide a graphical tool to make NewGRFs, but definitely not as powerful as you can make then in NML/NFO. So NFO, nor real world assembler, are ancient; actually, they're still very much alive but it has/will become a niche product, whereas higher level languages will be used more by others. It doesn't mean we should dump NFO, or assembler, and make OpenTTD work directly with NML source code, or CPUs directly with C code. They're just layers of abstraction that allow you to make something that you can work easily with, but that a "computer" can work with directly as well.

Long story short: yes, NFO might look ancient but that's NOT a reason to drop it. Actually, it's total lack of context means that it can "compile" source code with features developed after the release of the used GRFCodec version, and thus it's extremely useful for staying at the front of development. Higher level languages will have a lag between the specs getting changed and the compiler actually using the new features, as you'd need to wait for a new release.

[andythenorth]

Have you looked at the available content for download? There's not much there considering the number of people playing the actual game

I think, broadly, we don't much care about that

I don't speak on behalf of devs with commit rights. They can speak well for themselves. But I don't care about the amount of available content, and I'm not sure many devs do

But I could be wrong. There are hundreds of commits by multiple people working on nml for example. And there is a whole ecosystem of build system and code repository supported by OpenTTD Coop.

[Yexo]

Yep. You dismissed them because you now cannot implement those ideas because of how the direction of coding has gone. Right?`e.g. multicore awareness. I'm not an idiot, and I'd appreciate it if you'd not talk to me like one. I'd also appreciate you and the others not taking on that STUPID attitude of "if you don't like our way, then do it yourself". And no, you're not all able to make more feasible decisions on your own otherwise there would be multicore use, and there would be better tools available for creating content rather than ancient command line stuff that looks like it came from DOS. There would not be a cryptic complicated way of creating vehicles and graphics. The idea behind the openness of this game is so that ideas can come in and be discussed. As far as I've been reading on this forum, nobody has suggested easier tools and a better way to easily do what I originally started this thread about. To simply extract a vehicle (Sprites and all), be able to modify its parameters and create a new grf.

Let me quote a recent post from frosch which is very applicable here:

@bt80:
You and the guy you quote seem to have a general misconception of open source software. [0]

It is not the goal of everyone to rule to world, kill all companies and to enter a great utopic future. Idealists are generally a minority on every topic.
It is also not the goal of open source programmers to become popular and to clew up on how many users use their stuff. (We are not 15, nor act like that.)

Open source development only works in win-win situations. I.e. when those who do the work get something in return (in most cases "fun", "interaction with others" and/or "something useful they would not have archived alone"). The users otoh can freely share the fun as long as they do not add additional cost or excessive work (usually they need to compensate the server/hosting cost and such; and they need to relinquish some expectations wrt. user-support).

You keep complaining about easier tools for NewGRF development and that there are no suggestions about it. Doesn't the existence of NML prove the opposite? Please keep in mind that it's a huge project. It's been approximately a year since it was started and it's still nowhere near finished. Any GUI tool cannot possible give all the possibilities NFO / NML offer, it'll be limited anyway. Not only that, it'd be a huge project in itself.

[Alberth]

You dismissed them because you now cannot implement those ideas because of how the direction of coding has gone. Right?`e.g. multicore awareness.

The game *is* multi-core aware.
We have no problem throwing the whole code upside down to get more use of the processor capacity. Unfortunately, if we do that, we gain gain just a few percent while adding a LOT of complexity. It is just not worth the gain.
We can have more, but then we have to drop multi-player. (When we do that, we can re-organize the structure of the program so it fits better to multi-core.)

And no, you're not all able to make more feasible decisions on your own otherwise there would be multicore use

Right.
I only have a PhD in making a concurrently executing simulator using threads, obviously I am completely clueless with respect to multi-processing/multi-core issues.
Please master, come and teach us the right way.

and there would be better tools available for creating content rather than ancient command line stuff that looks like it came from DOS.

We rather concentrate on what you can do with the tool than on the packaging.

There would not be a cryptic complicated way of creating vehicles and graphics.

It still would be complicated, just in a different way.
There are so many settings that it is quite impossible to design a sane GUI for it.

The idea behind the openness of this game is so that ideas can come in and be discussed.

But you are not discussing ideas.
So far the only thing you have stated 'I want this and this and this.'
I replied 'we consider them not feasible'.
So the next step would be from you showing us why they are not as infeasible as we think.

An answer like 'Game X does it' is not enough. You'll have to explain it in technical details how to do it, and why it will not fail. We all want what you want (perhaps in slightly different form), but we don't understand how to get it. You seem to know things we don't, so please enlighten us. (Getting new understandings is always one of the joys of open source.)

To simply extract a vehicle (Sprites and all), be able to modify its parameters and create a new grf.

NewGRFs are like little programs, you cannot automatically extract a part out of it. The only possible way we found so far is by doing it manually. If it can be done automagically that would be great.

Have you looked at the available content for download? There's not much there considering the number of people playing the actual game.

Really? I think there are too many things there.

Now look at games like The Sims, and other such games. They have huge communities of people developing content because the tools are there and are easy to use.

Do you happen to have a few million dollar lying around to pay a hundred full time developers to create all those tools?

Even then, creating more content is simple, creating good quality content that is maintained over time is the real challenge.

Last but not least, the goal of OpenTTD and TTDpatch is not about making money or having a large community.

So why don't you guys cut the s*it, and sit down and talk to me about this rather than copping an attitude and dismissing me as unimportant and less superior.

Ok, then start explaining how we can make it work at technical level with the man power that we have.

You have seen what we have done so far, this is the best we can do with the resources that we have.

[frostnose]

Seriously guys,
Who is the largest know-it-all?

Look at "The Sims 2" where there was NO dev kits at all in the beginning. Sprites and layers where made in 3D studio max and the rest in Photoshop or even PAINT! So don't mention the work people has devoted their time to The Sims 2 community that flourished thanks to BASIC thinking from EA.
Guys in what cellar have you been the last decade?

Like with all OSS head developer; you really need to listen to the roots of the user base and really take those suggestions in consideration instead of rejecting it as usual. NO WOUNDER OSS DON'T WORK!
And pointing out "not going defensive" makes me sick! You are defensive from the beginning you gotten nowhere and rather be stuck in the bog-lands instead of attracting new IDEAS and DEVELOPERS!

[Yexo]

No wonder oss don't work!

I think you're just flaming, but in case you're not please read my previous post again (and the post from frosch I linked in it) and tell me exactly why you think it "doesn't work". Also explain what exactly "working" would be in this case.

[BillSargent]

Let me quote a recent post from frosch which is very applicable here:

@bt80:
You and the guy you quote seem to have a general misconception of open source software. [0]

It is not the goal of everyone to rule to world, kill all companies and to enter a great utopic future. Idealists are generally a minority on every topic.
It is also not the goal of open source programmers to become popular and to clew up on how many users use their stuff. (We are not 15, nor act like that.)

Open source development only works in win-win situations. I.e. when those who do the work get something in return (in most cases "fun", "interaction with others" and/or "something useful they would not have archived alone"). The users otoh can freely share the fun as long as they do not add additional cost or excessive work (usually they need to compensate the server/hosting cost and such; and they need to relinquish some expectations wrt. user-support).

You keep complaining about easier tools for NewGRF development and that there are no suggestions about it. Doesn't the existence of NML prove the opposite? Please keep in mind that it's a huge project. It's been approximately a year since it was started and it's still nowhere near finished. Any GUI tool cannot possible give all the possibilities NFO / NML offer, it'll be limited anyway. Not only that, it'd be a huge project in itself.

I have a different idea of what open source means. I believe that it means not only code is shared but ideas and philosophy about how the code is written, maintained and features of that code not only by the developers and the people who know the language, but by the users and people who support it. And I consider myself a very big fan of this game.

You're right about NML, I've already said that. I think its fantastic but its also a bit complicated. Why not XML? Why does everything need to be compiled in to binary garbage? A lot of other engines use text files and a general engine to control it all. I'm not even asking for a simple simple GUI, but just a GUI that has some ability to do the tasks without having to work in hex. NML is a good starting point for that.

Bill

[frostnose]

No wonder oss don't work!

I think you're just flaming, but in case you're not please read my previous post again (and the post from frosch I linked in it) and tell me exactly why you think it "doesn't work". Also explain what exactly "working" would be in this case.

You managed to build your self in to a dead-end with code from TTD. Why OSS don't work? Because every project makes the same mistake; basing the whole CORE on "ye olde code" instead of really starting over when it is legacy.

[Yexo]

I have a different idea of what open source means. I believe that it means not only code is shared but ideas and philosophy about how the code is written, maintained and features of that code not only by the developers and the people who know the language, but by the users and people who support it. And I consider myself a very big fan of this game.

So effectively you want to control what I and other work on because "you are a very big fan of this game". Sorry, but that doesn't work for me. I work on this game because I have fun doing so. I have fun doing so because I can freely chose what to work on. Sometimes that means working on something a lot of players want, sometimes it's just something technical you'll hardly see in game. It's never because you or any other big fan tells me what to work on.

You managed to build your self in to a dead-end with code from TTD. Why OSS don't work? Because every project makes the same mistake; basing the whole CORE on "ye olde code" instead of really starting over when it is legacy.

Feel free to join P1sim or Transport Empire and see how far you get. Starting over would mean a new project, it wouldn't be OpenTTD anymore and as such I consider it off-topic in a topic about OpenTTD.

[BillSargent]

The game *is* multi-core aware.
We have no problem throwing the whole code upside down to get more use of the processor capacity. Unfortunately, if we do that, we gain gain just a few percent while adding a LOT of complexity. It is just not worth the gain.
We can have more, but then we have to drop multi-player. (When we do that, we can re-organize the structure of the program so it fits better to multi-core.)

This is a big load of bull. I'm sorry but it is. It might be aware of it, but its not utilizing it. And you think that there won't be much gain? This game uses 25% of each of my cores right now. And what does this game spend its time doing? Calculating. And what is sped up by using more percentage of cores? calculations! The vehicles in this game spend their time pathfinding and that will be what is effected.

I only have a PhD in making a concurrently executing simulator using threads, obviously I am completely clueless with respect to multi-processing/multi-core issues.
Please master, come and teach us the right way.

Yeah I'm tired of being nice. I really don't think this is called for and I don't care what your credentials are. If you believe for a minute what you stated above to be true, you're PhD holds no merit because you learned absolutely nothing in your creation of "concurrently executing simulator using threads".

We rather concentrate on what you can do with the tool than on the packaging.

'

having a gui is not about packaging. In modern computing, being able to quickly do things efficiently is what its about. This isn't the early days of computing where people from the DOS days are complaining about the dummy Windows users, this is about what modern computing is. And I'm sorry, modern computing requires a GUI and usability, not command line driven garbage from 20 years ago. And I know a thing about this, I've been using computers since DOS 4. I'm also a web hosting provider for many web sites and I deal with the ancient garbage in Linux as well at a command line level. I'm going on 19 years of Linux experience. And let me tell you, given the choice of rummaging through a plain command prompt and using a nice GUI, I choose a GUI because in the end, its about productivity and getting things done in an easy manner.

It still would be complicated, just in a different way.
There are so many settings that it is quite impossible to design a sane GUI for it.

How about my earlier suggestion? XML and an XML editor? How about that? And why can't a GUI be designed? A lot of properties for things doesn't mean it can't be done.

So far the only thing you have stated 'I want this and this and this.'
I replied 'we consider them not feasible'.
So the next step would be from you showing us why they are not as infeasible as we think.

I've not said that exactly. I've stated that I believe "this" and "that" are things that could be something worth aiming for in the future. And Yes I'd love to see it now.

An answer like 'Game X does it' is not enough. You'll have to explain it in technical details how to do it, and why it will not fail. We all want what you want (perhaps in slightly different form), but we don't understand how to get it. You seem to know things we don't, so please enlighten us. (Getting new understandings is always one of the joys of open source.)

I never said game x does it. I said that The Sims has a huge following BECAUSE of its ease of use for creating content. In other words, the developers weren't complete morons and thought in advance which is all I'm suggesting here... that some thinking be done for the future so that in the future when an idea IS feasible, the entire code base doesnt have to be rewritten. You all want me to tell you how to do things. My ideas are more ideas than an actual adaptation. I don't mind being told you can't do something, but i still want to discuss why. I like to learn too, you know. But if you're going to give me answers like you did about the mutlicore stuff, you'll get no respect from me at all in regards to your answers. I can comprehend enough C to understand certain aspects of this game.

NewGRFs are like little programs, you cannot automatically extract a part out of it. The only possible way we found so far is by doing it manually. If it can be done automagically that would be great.

Why is that? In a database you have indexing that tells where everything is in relation to a record. Why isn't it done that way here? And it brings me back to my original question of why are we COMPILING grfs? Why can they not exist as plain text and individual sprite files? This is a real question, not a condescending statement. Is it the load time and disk access?

Really? I think there are too many things there.
Do you happen to have a few million dollar lying around to pay a hundred full time developers to create all those tools?

There's not nearly enough content for this game. And I think you're just being a smart-a** by stating that it would cost a few million.

Even then, creating more content is simple, creating good quality content that is maintained over time is the real challenge.

Last but not least, the goal of OpenTTD and TTDpatch is not about making money or having a large community.

You'll never have people interested in creating and maintaining content if its overly complicated to do.

And why do you not care whether OpenTTD has a large thriving community of players and content creators? It's a wonderful game. I suppose I have more appreciation for it than you do and a lot more ideas that frustrate me because I can't implement them myself.

Ok, then start explaining how we can make it work at technical level with the man power that we have.

You have seen what we have done so far, this is the best we can do with the resources that we have.

I'd love to talk to you about that but without the attitude all of you have displayed. Rather than have an adult conversation, you've all shown a superiority complex even to the point of spouting your stupid "credentials". Nobody really cares how smart you think you are. I never said I had answers technically. Since I've repeatedly stated that I do not have the level of C programming skills to do anything really, I cannot give those answers. You obviously have enough manpower to produce a fantastic game. So I can't believe for a minute if you all put your heads together some of the stuff could be done.

Bill

[Yexo]

I never said I had answers technically. Since I've repeatedly stated that I do not have the level of C programming skills to do anything really, I cannot give those answers.

• You don't have enough technical knowledge to discuss whether or not it's technically possible
• You don't believe the people that do have that technical knowledge

What more is there to say?

[BillSargent]

Arguably almost everyone, of influence at least, who says something can't be done say so because they have actually, privately, tried to change a particular aspect of the game. During that effort they came to the conclusion that it either doesn't work, or it doesn't provide a significant benefit, or it breaks backward compatability in some way.

So, before saying I'm hostile: I'm trying to figure out what how you intend to solve the problems you see. That way we can specifically point to "issues" that need to be solved before one could actually implement your idea, and maybe by specifying the proposed changes you'll find some other reasons why it won't work.

I don't think you're hostile at all. You've actually shown the most adult conversation from the people replying.

Also... your comparison seems to disregard scale. The Sims (1) has been sold 16 million times (by 2005), whereas the latest OpenTTD has some 200.000 downloads. That's two orders of magnitude difference, so a two order magnitude difference between content on Bananas and in the Sims wouldn't be that surprising.

The Sims 3 store's about page talks about hundreds of items/sets. It should have tens of thousands if its size would be linearly related to its user base, and OpenTTDs user to content ratio. A quick scan of The Sims 2 store (opened 2008) doesn't seem to have anywhere near tens of thousands of items either, and that's even older than bananas. So, does OpenTTD really provide less extra content per user?

YES.... I'm not talking about the Sims 3. EA Screwed up that game royally when they released 3. Version 2 had huge thrriving communities with TONS of addons. And they kept releasing new add on packs for it plus all the user content. I know several people personally who were hired by EA to develop content for EA's own add on packs. USe google and search for content for the sims 2. There are thousands of pages devoted to custom content. It's not all piled in one easy to access spot, mind you but there are huge forums and CMS managed sites that have loads of graphics and hacks. Are you positive about your 200,000 download stat? That seems very very low considering how long this project has been around.

Even then, The Sims sells mostly seperate items whereas OpenTTD have whole sets, consisting of dozens if not hundreds of vehicles, industries, houses, etc.

Well no thats not really true. Each addon set contains several sets of furniture and things. For example the H&M addon provided a lot of different clothing for your sims. They're not packs of hundreds of vehicles and I'd like to see you point me to a grf that has hundreds of vehicles in it.

Finally, with all (computer) programming you'll see that over time things get abstracted more, and a higher level language is introduced bringing it brought closer to the end user but less powerful. NFO is the most powerfull for NewGRFs, then comes NML (compare it to C), after that come things like GRFWizard/GRFMaker which provide a graphical tool to make NewGRFs, but definitely not as powerful as you can make then in NML/NFO. So NFO, nor real world assembler, are ancient; actually, they're still very much alive but it has/will become a niche product, whereas higher level languages will be used more by others. It doesn't mean we should dump NFO, or assembler, and make OpenTTD work directly with NML source code, or CPUs directly with C code. They're just layers of abstraction that allow you to make something that you can work easily with, but that a "computer" can work with directly as well.

Long story short: yes, NFO might look ancient but that's NOT a reason to drop it. Actually, it's total lack of context means that it can "compile" source code with features developed after the release of the used GRFCodec version, and thus it's extremely useful for staying at the front of development. Higher level languages will have a lag between the specs getting changed and the compiler actually using the new features, as you'd need to wait for a new release.

I'm suggesting that maybe the developers look for an alternative. NML is a good start as I've stated. But I also suggested XML where editors are already available. But thats just an IDea. There may be things wrong with that idea too. You know a lot of my frustration comes from the fact that I want to do things with this game that I can't because NewGRF is too complicated for me to grasp up front. Thats why I've gone on and on in this thread about tools and things.

Anyway I appreciate your nicer toned post.

[BillSargent]

So effectively you want to control what I and other work on because "you are a very big fan of this game". Sorry, but that doesn't work for me. I work on this game because I have fun doing so. I have fun doing so because I can freely chose what to work on. Sometimes that means working on something a lot of players want, sometimes it's just something technical you'll hardly see in game. It's never because you or any other big fan tells me what to work on.

No, but as a user and fan, I'd like to think my suggestions and input weren't met with sarcasm, and "nope" and "not fesible" and "you don't know what you're talking about". I appreciate the time you and others put in on this, but you need to focus some on your social skills as well. You have the social skills of a potato. I never said I wanted to control this. Suggesting that is very stupid.

You managed to build your self in to a dead-end with code from TTD. Why OSS don't work? Because every project makes the same mistake; basing the whole CORE on "ye olde code" instead of really starting over when it is legacy.

Feel free to join P1sim or Transport Empire and see how far you get. Starting over would mean a new project, it wouldn't be OpenTTD anymore and as such I consider it off-topic in a topic about OpenTTD.[/quote]

Well I don't think thats totally off topic. We're discussing a wide range of things here apparently.

[BillSargent]

I never said I had answers technically. Since I've repeatedly stated that I do not have the level of C programming skills to do anything really, I cannot give those answers.

• You don't have enough technical knowledge to discuss whether or not it's technically possible
• You don't believe the people that do have that technical knowledge

What more is there to say?

Apparently nothing, to you. Closed mind, closed ears, limited learning abilities and limited social skills.

You have heard nothing I've said, and twist what I say in to something wicked. All I asked for was a focus on easifying content creation and you mistook this as some kind of plot or ploy to take over and control your development. You're way too defensive.

I'm a very opinionated person, and I make no apologies for it. Because I don't know C doesn't mean I don't have valid input and valid ideas.

[BillSargent]

Oh one more thing, someone earlier stated that multi-core utilization would be bad for multiplayer games. Why not disable it for multiplayer games until that solution could be fixed? And I would guess that more than half the people using openttd are playing single player anyway. Again, just a thought... I'm not even suggesting you start over on the code or implement this. I understand the great effort it would take to implement multicore usage NOW, but IF such a thing could ever happen... and desync was a fear... why not just disable during multiplayer?


Bill

[Rubidium]

Why not XML?

XML is, conceptually, not much different from NFO. So yes, we could easily use XML. However... you'd still have to use all kinds of magic number, or syntax to tell what you actually want to do. Yes, you might be able to use non-hex code, but it'll still be a large specified blob of data. Just a different format, and that won't make it conceptually easier to make a vehicle NewGRF. The only thing is that its slightly easier to start with it, but in the long run you'll spend more time with XML as you need to type a lot more.
It would be almost trivial to create a XML variant of NFO, whether it's really useful to the end user is probably answered with "not really".

Why does everything need to be compiled in to binary garbage.

There are certain benefits related to checking (some) semantics before shipping it over the world, as is having all the graphics and metadata in one file good as you can't forget to add some files to an archive. Besides that, OpenTTD only supports reading directly from tar archives (they are uncompressed so we can read directly from the file without much overhead), and Windows users generally have difficulty creating tar files.

Ofcourse, if you design your own game you don't have to do that. However, given the roots of NewGRFs the current design is pretty clever, especially as it doesn't duplicate the code for reading sprites compared to the original graphics which is great for TTDPatch. Much later OpenTTD was born and found that there were lovely sets that it could support fairly easily, after all they already existed and there was a specification so they only needed to implement it. Given both are decendants of the same game, it makes sense to share extensions where possible. Again, when you design your own game you may make a different (design) choice.

For what it's worth, for 32bpp graphics you must actually use separate PNG files and they use a file name to tell which sprite they exactly are, which is far from really useful when you add sprites and such. However, it saves keeping lots of metadata in memory for sprites that aren't (and possibly never will be) used.

GRFCodec has a "feature" that removes extra transparant rows/columns of pixels around a sprite if they aren't used. This means that with a simple template you can draw all kinds of vehicles, houses and such and when those sprites are turned into "binary garbage" they are reduced to their minimum size. This in its turn is beneficial as OpenTTD needs to draw less lines/columns as thus it can draw them faster. Finally, the "binary garbage" format for mostly transparent sprites is that it even tells how much transparant pixels will follow, so it can just skip pondering about them. With the single PNG images we don't have such image shrinking code, nor do we have metadata about how much transparant pixels will follow. As such drawing will be slower.

Related to the multi threading "issue", it might be interesting to read what I have written before about it. Then you might get an idea why "it's just calculations, so you can do it on multiple cores" is something that doesn't quite hold in OpenTTD's case. Related to that, trains influence road vehicles and vice versa via level crossings.

[BillSargent]

I'm done arguing with all of you.

And I'd love to pull this back to my original request. Could someone PLEASE show me how to get an airplane like the dinger 1000 in to something I can edit and manipulate? That WAS the original request here when I started modifying engines.h ....

Bill

[michael blunck]

Some things don´t change.

regards
Michael

[Yexo]

Please avoid making multiple replies after eachother in the same topic, merge them in a single reply instead. For the sake of keeping this topic civil I'll ignore your insults and reply to the useful bits instead.

No, but as a user and fan, I'd like to think my suggestions and input weren't met with sarcasm, and "nope" and "not fesible" and "you don't know what you're talking about".

Maybe the reply "not feasible" was given, because, just maybe, having multicore support actually is infeasible?

As for your "easy GUI to create addons": have you seen a GUI for creating programs in C++ or any other language for that matter? A NewGRF is much more than just the graphics and some static data.