Transport Tycoon Forums

What the hell is a "+" view and an "X" view? A tile is a square, which is distorted to a rhombus due to the isometric view. each side of the rhombus is 32 pixels in length.

Besides, in the 640x480 days, I thought the the tiles were MUCH TOO BIG, to get a reasonable amount of information onto the screen. One was busy scrolling all the time when building a station. So with 1280x960, and 64x64 tiles, the tiles will be MUCH TOO BIG again, let alone 128x128 or 256x256. How much information do you need in a tile? I want to look there and see the kind of vehicle and/or structure, the player color and things like direction and velocity. I have no use for a bus sprite where I can see the mirrors of the vehicle.

Celestar

Celestar wrote: Besides, in the 640x480 days, I thought the the tiles were MUCH TOO BIG, to get a reasonable amount of information onto the screen.

agreed.... and now they are WAY TO SMALL.

you want to design for today, or tommorw?

most computer games are designed for computers that are 3-5 years ahead of the current average.

by the time any graphics are done at a currently good size, they will be out of date. waste of time IMO

also there can always be "zoomed out" but you cannot zoom IN on small graphics.

Alltaken

I don't see that resolution will increase much further. Not until every font setting but "small" in Windows renders a good number of programs unusable or illegible.

Celestar

I also don't see any problem with the current system. Of course, in the future we may need bigger graphics, but right now we have all these artists working on TTD sized graphics and we have at least half of the graphics we need to replace all the graphics and have an independant release. I think its stupid talking about drawing everything from scratch when we only have 2 or 3 artists even playing OTTD.

But if anyone wants to redraw all the graphics by themselves, noones stopping them.

Celestar wrote:What the hell is a "+" view and an "X" view?

X view is the one youre talking about, + view is from the top of the tile to the bottom of it.

mdhowe wrote:I also don't see any problem with the current system. Of course, in the future we may need bigger graphics, but right now we have all these artists working on TTD sized graphics and we have at least half of the graphics we need to replace all the graphics and have an independant release.

That's the point - in future we may need bigger graphics. So, why not draw them bigger now? Also, you can create 32x32 version from 64x64 image quite easily (er... mostly), right? But if you have 32x32 version only and want 64x64, you can start drawing a new image (sure, you can have anti-aliasing and such, but that won't add the missing details into the image). That's my oppinion

There's even been discussion about adding extra zoom level, because for some people (including me) the tiles are too small at bigger resolutions. So, this could solve the problem; 64x64 tiles, current zoom levels. You know, there are three levels of zoom in the game and most of the time the biggest zoom is used (at least by me). So what's the problem with zooming out on smaller resolutions?

CTRL+D == extra zoom level

OK, here's my idea to this discussion:

would it be possible to make it a plug-and-play system, in which there is an additional, doublesize zoom level (like ctrl+D), but with detailed textures.

I mean, if there are detail textures available in a specific place/directory, then the program automatically reads and uses them, otherwise it uses the default (of .grf added) sprites (maybe with some antialiasing, but that's your call)

Advantages:
-you don't have to redraw the whole game
-anything that has been already made, can be used in the future too (this is a great concern of mine, that if you radically change the graphics system, then all those artistic items will get useless)
-the PnP system means, any little piece of sprite can be drawn on its own, and added piece by piece, no need to wait for full packages to complete
-I think a size that is double of the current TTD is sufficiently detailed in today's games too
-can be modified later to have 3d models instead of 8way sprites (for turning/slanting on slopes), and in making it also PnP compatible, with the same benefits

I hear all of you talking about how great it would be to have 64 or maybe 128 pixel graphics. Well, as I've been a longwithstanding fan of TTD and always had an urge to make new graphics I took some time thinking of some concepts. Please read below and try to comment on the concepts. In the end I'll post a screenshot implementing some of these concepts in an example screenshot made in Blender.

Terms and definitions:

• Alpha transparancy Each pixel has an alpha value assigned which indicates the amount of transparancy. Mostly 1.0 (or 255) is deemed no transparancy and 0.0 (or 0) is deemed full transparancy.

• bpp Stands for bits per pixel. Each bit can hold a value which is either zero or one. The amounts of bits can indicate the total amount of possible values. 2 bits per pixel allows for 2*2=4 values or colors. 8 bits per pixel allows for 2*2*2*2*2*2*2*2=2^8=256 values or colours.. 24bpp allows for 2^24=1677720 (1.6 million) different colours.

Discussion

• 32 vs 64 vs 128 pixels width Actually, I really like the 32 pixels width used in OpenTTD right now: it offers a great deal of overview. However, if we want to make TTD 'modern', we'll seriously need to consider using 64 pixels width graphics. 128 pixels might pose some practical problems. Do not forget that 128 pixels is 4 times as large as 64 pixels. We'll need to distribute these graphics when they've been created. There will be a HUGE number of sprites (with huge I mean in the order of 3000-5000 sprites). Then make your calculations even if the sprites are done in JPG (they will be a PNG based format probably).
  
  Another issue here is the amount of detail: 128 pixels of width requires more detail in the sprites. This first appears to be a good thing, but don't forget that we actually will need to make these models. When we keep the models in a 3D package we can always consider later on to go to 128 pixels.

• Colordepth 24bpp vs 8bpp This is an issue which has multiple problems. As some of you might know: 8 bits-per-pixel allows for so called Pallette shifting. In essence your video-card makes a map from a number between 0 and 255 and assigns a color to each of these input numbers. A game can change this mapping to different colors, in essence making some animations much faster. It's a technique used A LOT in early 90's games but is not necessary anymore. The technique is used in TTD in the water and the fires above some factories. In fact: when TTD is played on Linux or Windows, Linux's SDL and Windows emulation layer make these transformations in software anyways.
  
  The advantages of using 24bpp are numerous: easier to make details, no more ugly dithering, better gradients, etc. etc.
  
  Last but not least, it allows for easier alpha-transparancy (see below).

• Alpha transparancy In fact the game already has support for alpha transparancy, but only at 1bpp (it is either on or off). When using 24bpp graphics it not only allows for seethrough glass, but more interesting things like shadows, reflections of objects in water, anti-aliased borders (no jagged borders of sprites anymore), and probably much, much more. I would deem it very important, but it should be discussed so we can make a good estimation of the performance penalties involved.

• Means of generation Like I discussed earlier: the game will need tons and tons of graphics. There are some issues which I will discuss beneath which will require even more sprites. Thats why I deem to generate A LOT of the sprites automatically. This, however, will be a big issue for the pixel-artists who are also on this forum (I really appreciate their great work I must say). As you will see in the picture at the bottom of this post, loads of the graphics can be rendered in a 3D visualisation program (such as Blender or 3D Studio). It is also possible to program these environments in such a way that they will automatically rotate the model, change parameters like height, combine different models together etc. etc. and thus create a lot of sprites automatically. For alpha transparancy we'll need another technique which I will call 'sprite substraction'. This means making a picture of a sprite with the projected medium, making it without it, then deducting sprite 1 from sprite 2, leaving us with the alpha mapping of shadows for example.
  
  Generating the sprites by hand might be possible, but I deem it would be more useful to have artists create the textures of the 3D models instead. It's hard and tough work, but it'll pay off in the long term.

• Curves, curves and curves Something the original maker of TTD couldn't do was make curved tracks, curved surfaces etc. etc. This was for a reason: if you make curves you'll need maybe 2-3 times as many sprites. Also, since the number of colours at that time was limited to 256 (8bpp), it probably wouldn't have looked 'right'. In essence there are two types of curves we can apply here:
  
  Curves in tracks Curves in tracks can be applied on two different levels: the first option is to use the existing model used in TTD and try to make sprites which will fit right. On issue here is that a certain piece of track will have to look at it's neighbors to see how it should go. Another option would be to allow wider curves spanning 2 or more tiles. This will be a very hard thing to do, especially for the coders.
  
  Curves in surfaces Curved surfaces will make the ground look A LOT more realistic. It interpolates between the angle of descend of the neighboring tiles and thus creates a realistic looking picture. In essence this ofcourse implies curved tracks since it would be strange to have a straight track running over a curved surface

• Quality management We'll need people to manage the quality of the sprites. It's easy to make sprites, but it's hard to make them fit in the overall picture of a game. Many people already said: that-and-that graphics set just doesn't 'feel' like openttd. I can imagine that A LOT. TTD used for example, A LOT of contrast in it's colours. To redo that, one has to try the same. I sincerely do <b>not</b> believe this is because of the use of 3D programs or something. It is purely the artist which makes the error.

• A concept picture Because I wanted to try some of the concepts named above, I've made a quick concept picture in Blender. I must stress that the detail of this picture is not of such high level that it reflects the amount of detail which can be put in the final spriteset. However, as this is only a concept, I felt that high amounts of detail and precission art-work is not what is asked for right now. See the attachment for the picture.
  
  Some of the things you can see in this picture are:
  
  24 bpp The image uses 24 bits-per-pixel. An alpha mapping can be made of, for example, the reflection of the bridge by reducing the image of the bridge with the water with an equal picture without the water.
  
  64 pixels tile-width The tiles used are exactly 64 pixels in width, doubling the width of a normal OpenTTD sprite.
  
  Curved surfaces Probably the most eye-attracting feature: the surface rate-of-ascend is an interpolation of the rate-of-ascend of it's neighboring tiles.
  
  Curved tracks Only using curved tracks when it can be applied to the original TTD tracks.</list>
  
  Still missing are some vehicles. I'll post an update on that as soon as I can. Vehicles is a thing of it's own, since it has some discussable options.
  
  I hope I've informed you A LOT with this (way too long Forum message). Hope to see some feedback on this.

Nice train bridge..

mauddib wrote:bpp Stands for bits per pixel. Each bit can hold a value which is either zero or one. The amounts of bits can indicate the total amount of possible values. 2 bits per pixel allows for 2*2=4 values or colors. 8 bits per pixel allows for 2*2*2*2*2*2*2*2=2^8=256 values or colours.. 24bpp allows for 2^24=1677720 (1.6 million) different colours.

Don't you mean 2^24=16777216 (16.7 million)?

Nice picture though, I see it's progressed a bit from when I last saw it.

Wow, nice picture.

Looks much better than Lomo, if you ask me.

Its amazing but that kind of detail will require a lot of artist work

My concern WITH!!!!! that, is how big would OpenTTD grow? 7mb is a realistic limit for 56k users.

About the bpp thingy: you're absolutely right... I used a calculator and 1.67771*10^7 is not 1.6 million but 16.7 million

About the size: well, look at the size of the current graphics. Multiply by 4 for the enhanced bpp, multiply by another 4 for the increased size, divide by around 3.5 because of compression algorithms. Then, if you want to have curved tracks and surfaces, multiply by 3 (wild guess). So, I guess all with all it gets about 16 times as big. Right now the sprites are around 6 MB in size, so that will make a staggering 96 MB of sprites! (please note: wild guess)

Keep up the great work. I like the tile size as well as the general look (being much better than Lomo is no criterion, because the graphics in Lomo suck big time (apart from the vehicle graphics)).

Using higher color depth and and tile size will make the game grow, by a pretty large factor. But we could try to split up data files so that you don't have to download them for every release.

Celestar

mauddib

would i possibly be able to get the 3d file you used to make that image.

i use Blender, i assume you were using 3d studio. but i would be keen to try and have a look what some of my already made buildings would look like at those sizes in the image. i have been making buildings for other projects. and could pump out a whole pile of buildings for a new graphic set.

your ground sprites are fantastic so i would not even consider touching them (like them to much LOL).

Alltaken

I agree with all that said your graphics is great. How long did it take to draw (model) it? It doesn´t look like some draft
2 Alltaken: He said that he used Blender for that.

Celestar wrote:Using higher color depth and and tile size will make the game grow, by a pretty large factor. But we could try to split up data files so that you don't have to download them for every release.

Like incremental patches? Sounds good.

Hadez wrote:I agree with all that said your graphics is great. How long did it take to draw (model) it? It doesn´t look like some draft
2 Alltaken: He said that he used Blender for that.

yeah whoops i missed that part. although i did read most of his post LOL.

i have the file now anyway, thanks to mauddib.

will post some images of things i have done in a sec

Alltaken