News:

Do you need help?
Simutrans Wiki Manual can help you to play and extend Simutrans. In 9 languages.

openTTD graphics crowd-funding

Started by sdog, July 20, 2015, 08:06:14 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sdog

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

Junna

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...

prissi

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).

Ters

Quote from: sdog on July 20, 2015, 08:06:14 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?!?

sdog

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.

Isaac Eiland-Hall

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. :)

IgorEliezer

Quote from: Isaac.Eiland-Hall on July 21, 2015, 02:50:09 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)

Ters

Quote from: sdog on July 21, 2015, 12:14:20 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.)

gauthier

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.

Ters

Quote from: gauthier 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.

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.

DrSuperGood

QuoteHowever, 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).

Ters

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.

prissi

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.

DrSuperGood

Quote from: Ters 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.
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).

Sarlock

Quote from: prissi 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.


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.
Current projects: Pak128 Trees, blender graphics

Ters

Quote from: DrSuperGood on July 24, 2015, 05:14:50 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.

Quote from: prissi on July 23, 2015, 09:44:58 PM
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.

Quote from: Sarlock on July 24, 2015, 06:31:05 AM
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.)

DrSuperGood

QuoteI 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.

Sarlock

QuoteMy 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.
Current projects: Pak128 Trees, blender graphics

gauthier

QuoteAnd 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.

Sarlock

Quote from: gauthier on July 25, 2015, 02:07:31 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).
Current projects: Pak128 Trees, blender graphics

Ters

Quote from: Sarlock on July 25, 2015, 12:46:05 AM
Sort of like this?

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

RedChico

#21
Quote from: Ters on July 25, 2015, 08:32:10 AM
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.




Quote from: Sarlock on July 25, 2015, 12:46:05 AM
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)

Sarlock

Quote from: Ters on July 25, 2015, 08:32:10 AM
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.


QuoteI 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.
Current projects: Pak128 Trees, blender graphics

jamespetts

As part of the city growth overhaul for Experimental, multi-tile city buildings are a possible addition, but that is not guaranteed yet.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ters

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.

prissi

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.

Sarlock

QuoteSo instead of one list, we would have three lists (1, 1x2, 2x2) or so for replacement, construction etc.

That seems easiest.
Current projects: Pak128 Trees, blender graphics