New graphics and using OpenGL?

[iridium]

Well, I did some actual testing and messing around to see how I'd go about it.

Please note that this is *nowhere near* a functioning entity, it is purely speculation and there may well be better ways of doing it.

Also this post kinda follows on from some of the other ideas I've heard around such as storing sprites in PNG format, and seperating the graphics engine and the gameplay engine; which may or may not be feasable.

I may also have greatly mis-understood the current graphics internals, and some of my post may be invalid.

This is mainly research for my own benefit and I'm in no way imposing it on OTTD. I'd be interested to hear your views on it, and how this might differ to using other methods.

As most of you know, the current graphics system works by blitting all of the sprites that the user sees in a frame, for every frame. This means that the CPU has to spend a lot of time transferring pixel data around.

[edit]I have just talked with Tron and this is *not* true. I had mis-understood the graphics code. Infact OpenTTD only redraws what is necessary. This is actually an advantage to opengl since opengl will have to redraw the entire frame for every draw. This invaildates a large amount of my post[/edit]

The aim is, one way or another - either by using OpenGL, SDL, or some other API - to eliminate this copying of pixel data, so that only positional data has to be specified for each frame.

This is done by having a texture containing lots of sprites, then drawing a quad (a square) in 3-D space, and specifying the texture co-ordinates which should be rendered onto this quad. The texture itself should always stay in video memory, and the video card should do all of the processing.

Good things about OpenGL:

• Smooth Zooming - OpenGL will provide an infinate number of levels of zoom with relatively little processor cost.
• Only positional data has to be sent for each frame.
• Positional data can all be specified in one huge array, and drawn using one function call.
• Alpha blending is made easy - textures can be full 32 bit colour.
• lighting? Explosions? weather effects?
• 3D vehicles?

Bad things (Well, not necessarily bad, but problems which need to be overcome or thought about carefully):

• Textures are going to use MASSIVE amounts of memory at 32 bit colour. Judging by the 800 x 18928 pixel image containing all of the sprites Celestar sent me, it is going to require upwards of 50mb. Also in another post I read about the idea of sprites being stored using PNG. The palettized image Celestar sent me was around 3-4mb in size. The RGB+A PNG image was 18mb in size.
• Textures must be powers of two in dimension. So we cannot just create a 800x18928 texture.
• By the time it all works out, no actual speed benefit? The experiments I've been doing involve rendering 256x256 quads and zooming in and out so that the entire map is visible. It renders nicely at 75fps (cap due to vsync) - but my CPU usage is somewhere up at 80%. I'm on an Athalon 2600XP+ with a GeForce 4 Ti4600 graphics card, which is all quite powerful. Transport Tycoon was designed for old systems which aren't going to be as capable. Culling may help though, I mean, who is going to want to see all 65535 tiles at once?
• OpenGL uses floating point positional data for nearly everything. This means that quite a bit of calculation may be required to align things and such.
• As far as I am aware, OpenGL cannot handle indexed sprites, this throws out palette animations [edit]Someone showed me a very nice demonstration of palette animations using opengl today. I take it all back.[/edit] - though OpenGL does provide functions for modifying small portions of large textures efficiently. Also palette animations could be replaced with multiple sprites.
• Potentially crippling to people with older computers.

Ideas:

• Generation of the textures at runtime. Take a large set of PNGs, and pack as many as possible into a relatively large texture. - This might take a while to load though.
• One texture for each different 'set' of things. Since there are limitations on the sizes we can make textures, it might be sensible to have several 4096x4096 textures. Also you can only specify one texture per array of positional data. So it would make sense to have a 'landscape' texture, and to then specify positional data for all of the landscape which needs to be rendered. And to have a 'buildings' texture, and an array of positional data for all of the buildings, and so on.
• (Re: PNG sprites) Do we really need 32 bit colour?
• Running graphics engine and gameplay/networking engines on seperate threads?

Disclaimer:

• A lot of this is speculation.
• I may be factually incorrect about a few things I have said.
• You may already be aware of the problems I have presented, I don't intend to be patronizing.
• OpenGL is NOT the solution to everything! there may well be better solutions, and some of the things I've written about in this post will apply to other APIs and solutions.
• Some of this post may not make sense because I may have assumed you know things just because I know them. Let me know if I need to explain anything more clearly
• I have no wish to stir up fights about whether we should be using one graphics API or another - I'm interested to know about the technical details.

If you have any questions or queries about what else OpenGL can do or can be made to do, or where it might fail, I would be interested to hear from you.

- Irid.

[MeusH]

Here is a few points, I think you've already made some ideas from below, but anyway, here it is:

Clip everything what is more at right, left, up, down than camera sees, in other words, don't draw this, what camera doesn't see

jpg textures! They can even be 64x64, but as far as you know, jpgs are compressed

Low poly models for everything but the landscape: rotating would be possible without changing size a lot

So, usage textures and models won't require 800 x 18928 zillion pixels image!

For super zoom out, change all terrain and models to super low poly. Disable effects (or change them to low-quality - with super zoom out player won't see difference, but computer will

[iridium]

after some dicussion with other people I've come to the conclusion that using OpenGL isn't going to give us any performance gains (or very little).

However, it might be handy in that it would reduce the number of landscape sprites required - plus it would provide features such as smooth zooming and oppertunites for other special effects.

If you have any thuoghts on the subject please do reply

[MeusH]

Anyway, I think OTTD can rock with OpenGL. And of course, good bye sprites I can make texture of model with same size (and better quality) of image.

For terrain, that's right, if there is long, flat area, you can use one GL_QUAD for it! And that's amazing!

[Archonix]

Using jpg for texturing is a big no. Lossy compression looks absolutely crap in OGL as far as I've seen. Better to use gif or png. It is possible to get png to compress quite well if you tweak the settings a little when you save, though of course it still leads to much larger file sizes. PNG can be saved as 24, 16 and 8 bit files without too much hassle as well.

If it were possible to seperate the graphices engine - and you seem to be saying it isn't at the moment - then creating an OGL engine as a seperate download would have been a possibility. Shame really, I wouldn't have minded seeing it...

If you did go the OGL route, you'd have to completely abandon the idea of using sprites to make it work efficiently. Everything would have to be textured 3d models, otherwise you loose a lot of the advantages. And the tiles, too. Completely seperate the rendering from the coordinate system. Use patches; high detail areas like hills get more quads, low detail areas and flat spaces get fewer quads. The "tiles" are rendered on top of the landscape either as atexture of an overlay of some kind.. The ultimate would be a completely flat map - one huge quad. It'd render blisteringly fast.

Then ther comes the bit that I can't remember the name of. You have a "big" texture that gets splattered across the entire map. That's used as a sort of definition for the placement of smaller textures that are varied depending on the larger texture, so some bits might look a bit sandy and others a bit grassy. Those textures then define even small textures. A bit of blending and you have a nicely varied landscape. You can even use fractals and save on the actual storage space the textures will take up.

I suspect I'm probably just rehashing your thoughts in this post. My brotherknows a hell of a lot more about this than I do so I might have to give him a call and get some info from him.

[MeusH]

Yeah, you're right about patches and texture blending.
But why not jpgs? highest quality jpg can be smaller file than same looking png.

About models, what format would you use?
And about effects, what format?
I think .efx is copyrighted to Id software, isn't it?

If it were possible to seperate the graphices engine - and you seem to be saying it isn't at the moment

Oh, what? I'm not saying about separating, I want one download

[Korenn]

Yeah, you're right about patches and texture blending.
But why not jpgs? highest quality jpg can be smaller file than same looking png.

About models, what format would you use?
And about effects, what format?
I think .efx is copyrighted to Id software, isn't it?

If it were possible to seperate the graphices engine - and you seem to be saying it isn't at the moment

Oh, what? I'm not saying about separating, I want one download

jpg has quality loss, ergo: not an option. even the highest quality jpg is not the same as a png. Plus jpg doesn't have alpha blending.

graphics artists aren't going to work hours on making everything pixel perfect only to see that jpg smudges it all over the place.

and who cares about those few kilobytes of space saved if you can have higher quality graphics?

[MeusH]

Oh, maybye you're right, but...

I can make 100% quality jpg (special feature) that will be anyway smaller than png. Photoshop, GIMP (free), and many more

Example: 512x512 png has 267 KB
Same jpg has 87KB

Oh, and I've made application in Delphi to check pixels... they all are same REALLY!



And yes, alpha blending...

blendFunc GL_ONE GL_ZERO
blendFunc GL_ONE GL_ONE
blendFunc GL_DST_COLOR GL_SRC_ALPHA

I hope that fits for you

[Archonix]

Well I can make a png that is smaller than a jpeg of the same dimensions. Easy when you know how.

[Korenn]

MeusH: those jpegs still lose quality!

and png is already in the game and working fine (although only used for screenshots now) so why implement (or link) an entire jpg library for no functional gain whatsoever?

[Killer 11]

if you plan to use jpg then i will stop playing with red company colour becouse jpg mostly f*** up the red color but all others are also efected.

PNG all the way!

[iridium]

This post wasn't supposed to be about the stored graphics format.

Both PNG and Jpeg have their advantages in different situations, I quite like the idea of using PNG because it would allow for the usage of an alpha channel, and the format is generally more flexable. Also, lossy compression is used quite a lot for 3D graphics textures, if it weren't, games would be huge.

[MeusH]

Allright, pngs. So let's not talk about jpgs

Iridium, could you response what format would be used for models and effecte, please?

[grater]

Switch to Full 3D:
Pros:
Nice map, rotating, zooming, stuff.
A new vehicle is just one model.
New graphical effects aka eye candy.
Effectively ends copyright issues regarding graphics.

Cons:
Lots of work.
No longer works (well) on older computers.
Splits the player/developer base.
May detract from the simplicity of the game somewhat.


Using OpenGL in a lesser role, that is, just to render the existing sprites, carries very few benefits, really the only one is smooth zoom and maybe a bit of extra graphics effects, but it wont really enhance the game at all beyond that small amount of eye candy.

Given that the game already has fully functional 2D rendering switching to 3D would be really, really hard to justify.

[iridium]

I agree with your sentiment, grater. However there is also talk about allowing for more levels of terrain, which means many more sprites, which would make the game bigger and possibly slower. Having OpenGL render the terrain in this sort of situation would be handy, not to mention vehicles with more rotational freedom, and such.

I don't think the idea should be thrown out of the window just yet, however it is not going to come about overnight, either.

[Archonix]

I suspect before you can even begin building an OGL engione, the graphics need to be completely decoupled from the rest of the game. Otherwise you'll be faced with all kinds of hacks and workarounds to get it working.

[Villem]

If you want turn OTTD into 3D, you would pretty much have to rewrite the core of the game totally.

[Prof. Frink]

If you want turn OTTD into 3D

join the Transport Empire group instead

[MeusH]

If you want turn OTTD into 3D, you would pretty much have to rewrite the core of the game totally.

Not much, just graphic one. Economy, vehicles, production will be the same.

No longer works (well) on older computers.

Works on win95, so this is old computer, I don't belive someone who has got internet (OTTD download source) has DOS or win 3x

Splits the player/developer base.

What do you mean? Players will be still able to make model, some info file (like nowdays .nfo files), pack it to one file, and it will work

May detract from the simplicity of the game somewhat.

It won't be UT engine but it can be perfect and simple

[lucaspiller]

I highly doubt OpenGL is going to work on my 6 year old Pentium 1 computer with a 2mb (w00t) graphics card... but I don't use it so I am not really bothered. My point is that I expect quite a few people will still be running old computers that don't support OpenGL.