The International Simutrans Forum

 

Author Topic: openTTD graphics crowd-funding  (Read 13438 times)

0 Members and 1 Guest are viewing this topic.

Offline sdog

  • Devotee
  • *
  • Posts: 2039
openTTD graphics crowd-funding
« on: July 20, 2015, 08:06:14 PM »
https://www.kickstarter.com/projects/1512547915/pineapple-graphics-for-openttd/description

Someone is running a kick-starter project, aiming for $24k, to draw a high-res graphics set for that game.

The images look extremely high-res. I wonder how they are going to run that in OpenTTD. It is blitting the tiles not too differently from simutrans, isn't it? Having a thousand 256 or 512 bit pixel wide images ought to be quite a load, even for recent systems.


edit: corrected part on image size
« Last Edit: July 21, 2015, 12:15:28 AM by sdog »

Offline Junna

  • Devotee
  • *
  • Posts: 1081
Re: openTTD graphics crowd-funding
« Reply #1 on: July 20, 2015, 08:10:52 PM »
I think the OTTD 32 bit graphics look absolutely horrendous no matter what. It has zero of the charm that regular OTTD has, and even when it looks good as such as pikkas 32-bit graphic sets do, it just looks warped, the way the vehicles are so short, and the general dreadfulness of how the  graphics scale at those sizes...

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9460
  • Languages: De,EN,JP
Re: openTTD graphics crowd-funding
« Reply #2 on: July 20, 2015, 09:29:53 PM »
Honestly the strechted diagonals and then vehicle length limit of TTD are really enhanced by the larger size. Not to mention that there can be only 16 steps per tile (if they did not completely changed it recently), as the movement code and display code are interlocked.

Such larger graphics would work much better using Simutrans (and reusing them is rather trivial).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #3 on: July 20, 2015, 09:34:16 PM »
256 or 512 bit images

I've heard of 128 bit images for doing blending with a wider range of colors. Even that seems overkill for something like OTTD. So 256? 512?!?

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: openTTD graphics crowd-funding
« Reply #4 on: July 21, 2015, 12:14:20 AM »
Sorry, it ought have read pixels not bits, I shall correct my post accordinlgy.

I've looked at the png in the kickstarter, the tiles appear to be 256 pixels wide.

As far as I know it 256*256 would be pushing the limits for simutrans. I thought OpenTTD had much more trouble with their graphics than simutrans. How are they going to run, 256*256/2. In the kickstarter it is also mentioned that the release is not before the next version of OpenTTD.


Besides, OpenTTD has a larger user base, it will be interesting if pikka can get the funding.

Offline Isaac.Eiland-Hall us

  • Benevolent Dictator
  • Administrator
  • *
  • Posts: 3649
  • PanamaCityPC.com/support/
    • Facebook Profile
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #5 on: July 21, 2015, 02:50:09 AM »
I think there was a 256x256 test pak for Simutrans at one point. It was really really big. lol. IMHO, 192x192 is about the largest I'd ever want to see - and when I play it, I usually play zoomed out (but it's nice to zoom in - and the cartoony style makes it work nicely imho).

We have some great artists out there and I love a lot of the paks - but I have to admit that I miss Raven and the Blender stuff. I really wish we'd gotten a full set of that look. Or if someone rendered things in a SimCity 4 like way...

I have a feeling that once money gets involved, though - feelings get hurt quickly. At least right now, anyone who has contributed knows that nobody has gotten money out of the deal. Well, except for donations toward the server during hard times, although I definitely didn't make any money from that. heh. (But I'm glad not to need donations again, too.)

That all being said - I wish OTTD the best of luck. Sounds like they have a lucky setup - one guy who already was contributing to the project... I hope it doesn't cause their community the distress that money can.

And although I don't particularly like the style I saw, it does look nice, and I know if it happens, it'll make for some happy OTTD players. :)

Offline IgorEliezer br

  • Devotee
  • Administrator
  • *
  • Posts: 4083
  • Cake recipes are cool... REALLY!
    • Igor Eliezer Architect and Urban Planner/Arquiteto e Urbanista
  • Languages: PT, EN, AutoLISP, Python
Re: openTTD graphics crowd-funding
« Reply #6 on: July 21, 2015, 03:46:15 AM »
I think there was a 256x256 test pak for Simutrans at one point.
I thought there are a 255 px limit... or maybe my mind just made that up.

(oh... my username)

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #7 on: July 21, 2015, 08:39:02 AM »
As far as I know it 256*256 would be pushing the limits for simutrans. I thought OpenTTD had much more trouble with their graphics than simutrans. How are they going to run, 256*256/2.

The bottleneck should not be the size of the images, but the total number of pixels to draw on screen. If you double the size (area) of each image, there will also be only half as many images on screen, so it cancels out. Actually, drawing half as many images that are twice as large, could actually be faster, depending on how things go with the caches. Since Transport Tycoon had (I assume) 64x64 images on 640x480 display, 256x256 images on todays 2560x1440 displays would give you the same view of the world, except for what was lost vertically going from 4:3 to 16:9, just with smoother graphics. That rendering 2560x1440 without hardware acceleratation is a problem is unrelated to the tile size. (Though my first attempt at getting Simutrans to use OpenGL would actually run fairly well with fewer and bigger tiles. It even ran okay with 64x64 tiles. But when zooming out, it broke down due to the sheer number of individual, though small, images to draw.)

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: openTTD graphics crowd-funding
« Reply #8 on: July 21, 2015, 10:57:44 AM »
I think that the main concern is not the number of pixels to display but the number of pixels to keep in RAM. Larger graphics mean Larger(^2) data size.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #9 on: July 21, 2015, 11:58:53 AM »
I think that the main concern is not the number of pixels to display but the number of pixels to keep in RAM. Larger graphics mean Larger(^2) data size.

RAM itself isn't really a concern. It is primarily how much must be copied to the screen that is of importance. And it will be cheaper to copy the same image twice, than two different images once each.

With 2 GB address space available on a basic 32-bit platform, that's 8000 uncompressed 32-bit 256x256 images. Since images are mostly transparent, I suspect that OTTD, like Simutrans, uses RLE compression. That would likely double that number. Of course, those that had umpteen add-ons and reached Simutrans' 64k image limit would run out of address space with such big images, but not RAM. However, neither Simutrans nor Transport Tycoon will normally use all images at the same time.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2644
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #10 on: July 21, 2015, 01:44:49 PM »
Quote
However, neither Simutrans nor Transport Tycoon will normally use all images at the same time.
Except the game has to be built around taking advantage of that. As far as I can tell from Simutrans it loads all images for a pakset into RAM when it loads a pakset. As such if the image is used or not does not matter as it is still in memory. This is why people ran into the sprite limit since all sprites are loaded into memory for a pakset at the same time (otherwise chances of them hitting the sprite limit even with thousands of addons is unlikely).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #11 on: July 21, 2015, 04:18:21 PM »
I wrote "normally", because in sandbox game without timeline, you can actually end up using all images at once, in theory. Only spring and autumn images are truely mutually exclusive, but seasonal transitions are slow enough as they are, without Simutrans having to load the images in and out of RAM. (One could anticipate the transition, and start loading early, but then the time were the images are not loaded dwindles. And so does the usefulness.)

Besides, Simutrans problem was with the unique identifiers for the images, which would most likely have to exists permanently even if the actual image data could be loaded on demand.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9460
  • Languages: De,EN,JP
Re: openTTD graphics crowd-funding
« Reply #12 on: July 23, 2015, 09:44:58 PM »
The 256 size limit (was rather a 64k size limit per image) has been lifted a long time ago.

OpenTTD has only 64x64 and 256x256 image, nothing in between. The only mod I really like was the western mod (never released though):
http://www.badbrett.se/goldrush/?p=gallery

There are some house graphics on that page, so one may start a derivate of that for Simutrans. However, it really shows what non-textured tile can achieve.

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2644
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #13 on: July 24, 2015, 05:14:50 AM »
I wrote "normally", because in sandbox game without timeline, you can actually end up using all images at once, in theory. Only spring and autumn images are truely mutually exclusive, but seasonal transitions are slow enough as they are, without Simutrans having to load the images in and out of RAM. (One could anticipate the transition, and start loading early, but then the time were the images are not loaded dwindles. And so does the usefulness.)

Besides, Simutrans problem was with the unique identifiers for the images, which would most likely have to exists permanently even if the actual image data could be loaded on demand.
One could do a simple caching implementation. When one loads a pack for the first time it creates a "sprite sheet cache" file. This file is memory mapped to form the memory for the internal sprite sheet when it gets created. Subsequent loads of the pakset then map the file in read-only mode and do not need to build the sprite sheet again from all the individual pak elements. Due to the mechanics of memory mapping it will stream in pages as required (with a page fault), leaving the un-touched pages out of memory. This could be extended beyond sprites, to even pakset data so it gets loaded on demand.

If this works well is another question. Although memory mapped virtual address space is treated like normally allocated address space as far as the program is concerned, if it performs the same is another question (one that is hard to get a clear answer for). It also does nothing to combat limitations such as 2-4GB virtual address limit (since the mappings eat into the limit). Additionally due to the nature of pagefaults it is possible that users who just load up a session might have very bad performance initially as all the needed data is loaded into memory on demand. Let us not forget that the cache files will probably be quite big (possible concern for very old systems, or systems with little storage space).

Offline Sarlock

  • Devotee
  • *
  • Posts: 1340
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #14 on: July 24, 2015, 06:31:05 AM »
The 256 size limit (was rather a 64k size limit per image) has been lifted a long time ago.

OpenTTD has only 64x64 and 256x256 image, nothing in between. The only mod I really like was the western mod (never released though):
http://www.badbrett.se/goldrush/?p=gallery

There are some house graphics on that page, so one may start a derivate of that for Simutrans. However, it really shows what non-textured tile can achieve.


I'm assuming they are doing an alpha channel blending between the tiles and also for the shadows and smoke.

I've done a lot of playing around with graphics and different sizes and frankly I think 256x256 is far too big for a usable tile size.  It looks nice but I can't imagine anyone zooming in to that level except on the rare instance to look at the pretty graphics or post a screenshot.  Otherwise you'll be zoomed out a few levels in order to get a larger view of the transportation network.  128x128 is a good size though I've been playing with 64x64 more lately from a graphics perspective and it is quite powerful if the graphics are done right.  It looks great and the player is more likely to be playing at a natural 1:1 zoom level.

What would really add to the look would be ground textures.  We could use ground objects, that would probably work.  We just need a way to apply them in the game (add to tree menu?) so that they become a usable tool instead of being stuck with whatever spawns and not being able to add it back later if it's bulldozed.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #15 on: July 24, 2015, 08:48:43 AM »
One could do a simple caching implementation. When one loads a pack for the first time it creates a "sprite sheet cache" file. This file is memory mapped to form the memory for the internal sprite sheet when it gets created. Subsequent loads of the pakset then map the file in read-only mode and do not need to build the sprite sheet again from all the individual pak elements. Due to the mechanics of memory mapping it will stream in pages as required (with a page fault), leaving the un-touched pages out of memory. This could be extended beyond sprites, to even pakset data so it gets loaded on demand.

If this works well is another question. Although memory mapped virtual address space is treated like normally allocated address space as far as the program is concerned, if it performs the same is another question (one that is hard to get a clear answer for). It also does nothing to combat limitations such as 2-4GB virtual address limit (since the mappings eat into the limit). Additionally due to the nature of pagefaults it is possible that users who just load up a session might have very bad performance initially as all the needed data is loaded into memory on demand. Let us not forget that the cache files will probably be quite big (possible concern for very old systems, or systems with little storage space).

I don't see what's to be gained from that, apart from perhaps a slightly faster pak set loading time. All user space memory is in effect memory mapped, the only difference is whether the underlying file is the OS swap file or some specific file. You'd need to do something more clever than just mapping in the entire file, but that sort of cleverness could be done without memory mapping an image sheet. Although I guess memory mapping would be faster than parsing pak files. Whether it is fast enough to be seamless when playing, I don't know. I've never done manual memory mapping.

OpenTTD has only 64x64 and 256x256 image, nothing in between. The only mod I really like was the western mod (never released though):
http://www.badbrett.se/goldrush/?p=gallery

There are some house graphics on that page, so one may start a derivate of that for Simutrans. However, it really shows what non-textured tile can achieve.

Considering Simutrans creates images for all slopes and transitions anyway, "all" it takes is to make it possible for the artist to specify each and everyone of images these manually, rather than just supply the base textures and light maps. Non-smooth slopes, like the rounded cliffs in Gold Rush, would be a bigger problem, since these can't be part of the slope tile image. That would look really strange when a track is built. It would have to be a ground object, but then the world generator would have to know to place them there. And there would need to be either multiple ground objects, one for each rotation, that is placed correctly, or a single ground object that automatically joins up it's visual presentation like tunnel openings can do, except this time in two dimensions.

I've done a lot of playing around with graphics and different sizes and frankly I think 256x256 is far too big for a usable tile size.  It looks nice but I can't imagine anyone zooming in to that level except on the rare instance to look at the pretty graphics or post a screenshot.  Otherwise you'll be zoomed out a few levels in order to get a larger view of the transportation network.  128x128 is a good size though I've been playing with 64x64 more lately from a graphics perspective and it is quite powerful if the graphics are done right.  It looks great and the player is more likely to be playing at a natural 1:1 zoom level.

My main grief with 128 tile size, is that railroad tracks become very widely separated. I would have wanted 128 sized buildings and vehicles, maybe even roads, but on a 64 pixel tile grid, with 64 sized track segments. And it seems to me that those playing on pak sets with a tile size larger than 64 do a lot of zooming out, which I as a pak64 player almost never do (on purpose). So it seems that pak128 really is like a pak64 with a higher quality "detail view" that let's you take a closer look for "trainspotting". (I remember doing a lot of trainspotting in Railroad Tycoon 3. With it's 3D world, you could even sort of ride the train, looking out horizontally. You had to rotate the camera manually when the train turned if I remember correctly.)

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2644
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #16 on: July 24, 2015, 03:38:58 PM »
Quote
I don't see what's to be gained from that, apart from perhaps a slightly faster pak set loading time. All user space memory is in effect memory mapped, the only difference is whether the underlying file is the OS swap file or some specific file. You'd need to do something more clever than just mapping in the entire file, but that sort of cleverness could be done without memory mapping an image sheet. Although I guess memory mapping would be faster than parsing pak files. Whether it is fast enough to be seamless when playing, I don't know. I've never done manual memory mapping.
I gave it as an example of on-demand streaming of data. In the end how much memory a process allocates is pretty meaningless as performance is governed by how much memory bandwidth it uses (minus that saved by the processor cache) and how much of that memory is in use. Although it would not reduce the process address size, it would reduce the process memory footprint since it would only stream in to memory the data it needs to use, rather than all data. On the other side of the problem when pages are unloaded due to insufficient memory it would cause soft page faults rather than hard ones since no writing has to occur (unlike with the page file). If it is faster comes down to if those pages perform the same as normal pages.

Offline Sarlock

  • Devotee
  • *
  • Posts: 1340
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #17 on: July 25, 2015, 12:46:05 AM »
Quote
My main grief with 128 tile size, is that railroad tracks become very widely separated. I would have wanted 128 sized buildings and vehicles, maybe even roads, but on a 64 pixel tile grid, with 64 sized track segments. And it seems to me that those playing on pak sets with a tile size larger than 64 do a lot of zooming out, which I as a pak64 player almost never do (on purpose). So it seems that pak128 really is like a pak64 with a higher quality "detail view" that let's you take a closer look for "trainspotting". (I remember doing a lot of trainspotting in Railroad Tycoon 3. With it's 3D world, you could even sort of ride the train, looking out horizontally. You had to rotate the camera manually when the train turned if I remember correctly.)

Sort of like this?



This is a pak64 format but using a 128 pixel train set and trees are even larger, to conform to scale, 192 pixels for some, 224 for others.  This is a long term project that I am working on to accomplish exactly that -- a pak64 sized pakset that uses a realistic scale.  Buildings and vehicles will be 128+ pixels in size.  This will require manual placement of buildings, as they will be 2x2 tiles or larger.  If and when multi-tile buildings are available in the game, this will just be a manual pakset for designers, not a functional pakset for playing.  I like the idea of a 64 pixel base for ways (roads, rails, etc) but larger, to-scale, vehicles travelling on them.

That two-way railroad in the image is two 64-pixel tiles with the rails on the inside the tile so that they are nice and close together, like an actual double-track.

64 pixel tiles also allow for a lot more variation in ground elevations.

What I really need now is ground textures, but this requires an interface in the game to add them manually.

Offline gauthier

  • Devotee
  • *
  • Posts: 3629
    • SNFOS'website (in both FR and EN)
  • Languages: FR, EN, JP
Re: openTTD graphics crowd-funding
« Reply #18 on: July 25, 2015, 02:07:31 AM »
Quote
And it seems to me that those playing on pak sets with a tile size larger than 64 do a lot of zooming out
I don't know about other players, although as far as I'm concerned, I play pak128 without zooming out. Maybe it has something to do with size of screen ? Mine is 1600*900.

Offline Sarlock

  • Devotee
  • *
  • Posts: 1340
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #19 on: July 25, 2015, 03:01:27 AM »
I don't know about other players, although as far as I'm concerned, I play pak128 without zooming out. Maybe it has something to do with size of screen ? Mine is 1600*900.

I'm at 1920x1080 and almost always have pak128 zoomed out 2x (effectively making it 64 pixels).

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #20 on: July 25, 2015, 08:32:10 AM »
Sort of like this?

Yes. One big drawback that I suspect is that vehicles will stick out a lot more when turning.

Offline RedChico

  • *
  • Posts: 3
  • Languages: PT, EN
Re: openTTD graphics crowd-funding
« Reply #21 on: July 25, 2015, 02:26:49 PM »
Yes. One big drawback that I suspect is that vehicles will stick out a lot more when turning.

Chris Sawyer's Locomotion

I.e. more than 8 ways for track/road placement.



Sort of like this?

(...)

this will just be a manual pakset for designers, not a functional pakset for playing.  I like the idea of a 64 pixel base for ways (roads, rails, etc) but larger, to-scale, vehicles travelling on them.
 (...)

I like it very much... too.
Make it playable them.  8)
« Last Edit: July 25, 2015, 03:21:36 PM by IgorEliezer »

Offline Sarlock

  • Devotee
  • *
  • Posts: 1340
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #22 on: July 25, 2015, 04:13:34 PM »
Yes. One big drawback that I suspect is that vehicles will stick out a lot more when turning.

Correct.  Small price to pay, however, but others may disagree upon seeing that effect.


Quote
I like it very much... too.
Make it playable them.

It will be sandbox playable, but otherwise it can't be run as regular a Simutrans game, because all of the buildings will be 2x2 or larger and will require individual manual placement as attractions.  There will also be some graphical clipping errors with the large scale tiles on a 64 pixel grid.  But certainly works well for sandbox playing/creations and screenshots.  For the project I am working on, being to scale (or at least, mostly) is the most important factor.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Devotee
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #23 on: July 25, 2015, 07:01:43 PM »
As part of the city growth overhaul for Experimental, multi-tile city buildings are a possible addition, but that is not guaranteed yet.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 5478
  • Languages: EN, NO
Re: openTTD graphics crowd-funding
« Reply #24 on: July 25, 2015, 08:37:51 PM »
Wasn't some multi-tile building concept introduced in Simutrans standard a year ago or more? I thought it was something coming from an initiative for Experimental, but I didn't pay much attention to it. Just something I noticed in the SVN logs. Something by Neroden? Maybe it isn't complete.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9460
  • Languages: De,EN,JP
Re: openTTD graphics crowd-funding
« Reply #25 on: July 25, 2015, 09:58:02 PM »
You could use the cluster parameter; but while multitile city building would not be impossible. But I would think lerge tiles would be always replaced by the same large size. So instead of one list, we would have three lists (1, 1x2, 2x2) or so for replacement, construction etc.

Offline Sarlock

  • Devotee
  • *
  • Posts: 1340
  • Languages: EN
Re: openTTD graphics crowd-funding
« Reply #26 on: July 26, 2015, 06:38:25 AM »
Quote
So instead of one list, we would have three lists (1, 1x2, 2x2) or so for replacement, construction etc.

That seems easiest.