Regarding 3D

[uzurpator]

The main problem is that in order to use OpenGL effecively you must render whole the screen for each frame

No - ever heard of hardware buffers? From the game code you would just update objects in a scene which have really changed. heck - with use of vertex buffers you might need to just synch your scene say - once per five seconds.

(while now we render only what has changed). The benefit is that with optimizations (i.e. all sprites loaded as textures into video memory together with precompiled display lists) the rendering is so fast that it doesn't need to render only changed regions.

That is true regardless of technology

But doing that would mean to dedicate whole rendering code to OpenGL only, meaning that on older computers (and maybe on some other platforms too) it would be much slower (and unplayable) than now due to missing proper 3D acceleration support.

Intrestingly I played quake on pentium 100 with 8megs of memory and voodoo 3d hardware acceleration - all the way back in 1997.

So on one hand it would open possibility to go to 3D world easily and without performance problems (i.e. on good HW you can render 10000 sprites or polygons with >500 FPS), on the other hand we would support only new hardware (i.e. >P4 w/ >2 GHz, >=1GB RAM, >64 MB video RAM, etc.).

Ie - junk sale computer of today.
http://www.lauschangriff.org/bilder/rev ... 220335.jpg
Warcraft 3 - runs super smooth on Duron 700 with Geforce 4 MX.

To be a frank - with just using 3D acceleration for OTTD the game would look the same - with the exception of 600 fps. Rendering would be the least of your worries.

Frankly - id KILL for extra smooth TTD.

[KUDr]

So on one hand it would open possibility to go to 3D world easily and without performance problems (i.e. on good HW you can render 10000 sprites or polygons with >500 FPS), on the other hand we would support only new hardware (i.e. >P4 w/ >2 GHz, >=1GB RAM, >64 MB video RAM, etc.).

Those specs are bull. Detailed 3d games - at least in the detail ottd requires - can run on much lower spec systems.

I hate it when people scaremonger like this. Post some real research instead of made up guesses.

charlieg: Any reason for such arrogancy? What you mean by "scaremonger like this"?

On my PC (AMD 64 X2 2.2 GHz) with 256MB X800 graphics it did 630 FPS with 10000 textures 32x32 drawn randomly in one frame (from set of 1000 textures) in QUAD mode with alpha channel and Z-buffer (windowed mode 600x400).

Same program on Duron 800 MHz with old 4MB PCI graphics card without 3D HW support made 2-3 FPS.

What about to render only changed regions into texture? On other hand it will allow more polygons in screen at same time.

Try it if you know how. I have no idea

[KUDr]

No - ever heard of hardware buffers? From the game code you would just update objects in a scene which have really changed. heck - with use of vertex buffers you might need to just synch your scene say - once per five seconds.

Heh, what you mean by 'hardware buffers' and 'scene'? There is just list of sprites and quads. They can be stored easily in the video RAM (or HW, if any), but still they need to be rendered every frame. Otherwise you can forget about swapping video buffers and so on.

But doing that would mean to dedicate whole rendering code to OpenGL only, meaning that on older computers (and maybe on some other platforms too) it would be much slower (and unplayable) than now due to missing proper 3D acceleration support.

Intrestingly I played quake on pentium 100 with 8megs of memory and voodoo 3d hardware acceleration - all the way back in 1997.

1. Quake in 1997 didn't need to draw 10k+ polygons. Try some full 3D strategy.
2. And even better, try some full 3D strategy game using OpenGL on some PDA.

So on one hand it would open possibility to go to 3D world easily and without performance problems (i.e. on good HW you can render 10000 sprites or polygons with >500 FPS), on the other hand we would support only new hardware (i.e. >P4 w/ >2 GHz, >=1GB RAM, >64 MB video RAM, etc.).

Ie - junk sale computer of today.
http://www.lauschangriff.org/bilder/rev ... 220335.jpg
Warcraft 3 - runs super smooth on Duron 700 with Geforce 4 MX.

To be a frank - with just using 3D acceleration for OTTD the game would look the same - with the exception of 600 fps. Rendering would be the least of your worries.

1. The same as the previous point. You totally ignore HW without 3D acceleration.
2. Did you try to zoom it out (i.e. 5x) to see 25x more polygons? And did you ever think why so many 3D strategy games don't allow such zoom-out? Try guess... You are smart guy

Frankly - id KILL for extra smooth TTD.

Yes, mee too. But it is not rendering problem. Just now the rendering takes here <3% CPU.

BTW: some progress with TE? Or some screenshots with FPS?

[uzurpator]

Heh, what you mean by 'hardware buffers' and 'scene'? There is just list of sprites and quads. They can be stored easily in the video RAM (or HW, if any), but still they need to be rendered every frame. Otherwise you can forget about swapping video buffers and so on.

Hardware buffer is an entity that allows to load geometry into the graphics card memory and then call it when needed. This allowed me to draw 1024x1024 tile (2Mpolys) with very good FPS on radeon 9600 pro (let his remains rest in peace).

1. Quake in 1997 didn't need to draw 10k+ polygons. Try some full 3D strategy.

Total annihilation? Full 3d, and even run in software... Btw - quake2 or unreal did draw 5-10kpoly scenes in 1997.

2. And even better, try some full 3D strategy game using OpenGL on some PDA.

One of those that runs Quake? Considering that PDAs these times - with 400 mhz CPUs, no problem really.

1. The same as the previous point. You totally ignore HW without 3D acceleration.

For a standalone PC that would be?

2. Did you try to zoom it out (i.e. 5x) to see 25x more polygons? And did you ever think why so many 3D strategy games don't allow such zoom-out? Try guess... You are smart guy

http://www.gamehouse.cz/images/3662_3.jpg
in RT3 you could zoom out as far as you wished. In most cases it would improve frame rate. The game had awful pathfinding though (giant resource hog)

Yes, mee too. But it is not rendering problem. Just now the rendering takes here <3% CPU.

Which only proves that adhering to early 90ties technology is not efficient. Does OTTD still use the 'tick' mechanism from original TTD or is frame based? Really - 200FPS OTTD would rock :>

BTW: some progress with TE? Or some screenshots with FPS?

Progress in TE is slow, but steady. No screenies yet, except for the terrain generator which you can find in TE section. That runs at constant 25 fps tho ;>

As a philosophical note. If OTTD would move to 3d, then the only reason to do so would be to explot 3ds quirks - easier resource creation, free rotate, smooth curves etc. Currently it makes no sense at all.

[KUDr]

Sorry. It is the same song again and again. The HW buffer for whole scene has 2 important drawbacks:
1. you need sophisticated logic that would break the scene to static and non-static objects, record all static objects into HW and render them as first for each frame and then render the rest (there is no easy way how to update the scene which is already compiled in the HW).
2. and again: OTTD must run on HW without HW scene buffers (which makes all this discussion useless).

I think that It really makes no sense to continue. You still see only HW with full 3D acceleration support (or some sophisticated SW solutions to workaround that - RCT3). This is not what we were talking about nor what will happen with OTTD.
I used standard HW rendering (and its generic SW emulation with the old HW) and results were very bad without 3D acceleration (as expected).


Yes, OTTD is still based on old ticks. At least object movement must stay so. It is not going to change because it would break MP.

And yes, full 3D camera + smoother object movement would be the reason why it makes sense to talk about 3D in case of OTTD. But my motivation was to try how difficult it would be to stay in 2D and allow some (new) graphics be rendered as 3D. This would allow:
1. smoother zoom control
2. step by step move to full 3D graphics

[uzurpator]

Sorry. It is the same song again and again. The HW buffer for whole scene has 2 important drawbacks:

You are not using HW buffer for the whole scene...

Currently in TE i have 16k of possible tiles precompiled (takes about 1 megabyte, yest, that is 16k of small buffer objects) and I just skin and render them without rebuilding. The same for all vehicles. Frankly I am just composing the scene from precompiled blocks.

In case of OTTD you just need to create a set of billboards, load them to main video memory and then just move about. All TTD artwork would take approx 5-10 megs of video memory. That is close to nothing. And still you can add particle overlays, atmospheric effects, lightning etc. VooDoo1 would handle that nicely

1. you need sophisticated logic that would break the scene to static and non-static objects, record all static objects into HW and render them as first for each frame and then render the rest (there is no easy way how to update the scene which is already compiled in the HW).

Unless you are using a freeform terrain or some such, there is very little need to do things on the fly. The most task intensive part - calculating normals - isn't even needed in TTD.

2. and again: OTTD must run on HW without HW scene buffers (which makes all this discussion useless).

No. Different OTTD mutations should adhere to a single protocol. But that would require a hard architectural change, which is imvho much more time consumig then porting to 3d accelerated graphical client.

I think that It really makes no sense to continue. You still see only HW with full 3D acceleration support (or some sophisticated SW solutions to workaround that - RCT3).

I don't see a reason to develop 3D version in software (which isnt all that difficult) of the game when 95% of players have a 3d accelerator of some sort.

This is not what we were talking about nor what will happen with OTTD.

To paraphrase patchman - it will happen when someone does it.

I used standard HW rendering (and its generic SW emulation with the old HW) and results were very bad without 3D acceleration (as expected).

Obviously. Software 3d rendering is always slower then hardware. But as a counterbalance - in Diablo II the 3d "accelerated" version was slower then pure software :>

Yes, OTTD is still based on old ticks. At least object movement must stay so. It is not going to change because it would break MP.

And this is the most fundamental problem. Using archaic architecture makes creation of different clients much more difficult. ie - full 3d client could be created if there was a protocol to follow.

[peter1138]

All TTD artwork would take approx 5-10 megs of video memory. That is close to nothing. And still you can add particle overlays, atmospheric effects, lightning etc. VooDoo1 would handle that nicely

Most Voodoo 1s only had 4MB (I think the max was 6MB) memory, including the frame buffer itself, so, it wouldn't really fit...

And this is the most fundamental problem. Using archaic architecture makes creation of different clients much more difficult. ie - full 3d client could be created if there was a protocol to follow.

The game engine uses ticks and is not a problem, as there's no reason the graphics engine has to render at that rate. It does have to 'pause' while the game engine runs once every 30 ms though.

I'd say making the game engine work based on frame rate is more so archaic, thinking of those old games that relied on the speed of an 8086 and CGA graphics card and won't run on anything even 15 years old...

[uzurpator]

Most Voodoo 1s only had 4MB (I think the max was 6MB) memory, including the frame buffer itself, so, it wouldn't really fit...

Really? My memory seems to fail me :> Ok - make that voodoo2.

The game engine uses ticks and is not a problem, as there's no reason the graphics engine has to render at that rate. It does have to 'pause' while the game engine runs once every 30 ms though.

Actually - you want the highest frame rate possible with your hardware. Besides - 30 ms makes something like 30 fps.

I'd say making the game engine work based on frame rate is more so archaic, thinking of those old games that relied on the speed of an 8086 and CGA graphics card and won't run on anything even 15 years old...

Ideally the screen update should be detached from game logic. ie - game runs in 50ms time windows, while graphics is updated as fast as possible. Virtually all modern games use such approach. And problem with that games it that they were based on cpu-speed, not actual time.

[peter1138]

Ideally the screen update should be detached from game logic. ie - game runs in 50ms time windows, while graphics is updated as fast as possible. Virtually all modern games use such approach.

This isn't necessary when the view is static, because nothing will change while the game engine isn't running...

[uzurpator]

This isn't necessary when the view is static, because nothing will change while the game engine isn't running...

Say we can update the screen in 10 ms, but have 30 ms of time.
Object X will move by 18 units.

Instead of using 1 update (and move object by 18 units) and then wait, we update 3 times inbetween two engine runs, each time moving the object by 6 units. That is called movement approximation. Introduced in, afair, quake 2.

Vertex shader can do that for you.

[peter1138]

Two ways of doing this:

1) Actually move the vehicle on a frame. That would be pretty much impossible keep in sync in network games, and would probably require a change in game units as currently a tile is 16 x 16 units

2) Leave the vehicle's position where it was at a game-tick, and guesstimate where it would be when rendering based on the vehicle's speed, direction and time since last tick. This would probably result in strangeness at deadends, turns and signals...

[Psistorm]

@peter:
this would only result in strangeness if the ping was very high or if packetloss occurred. I cant tell just how often OTTD sends network packets for the vehicle positions and all that - but I guess its once per 30ms to stay in synch with the game engine itself.
this should be a sufficiently high data rate imo, after all multiplayer FPS games dont suffer from this effect either, only in times of high pings and lags.

and since I just re-read your post:
the game engine can be trusted to reliably send a position update every 30 seconds. now then, how far would even a maglev move in 30ms? the interferences caused by interpolation would be somewhat minimal, since we wouldnt have to expect anything such as lag.

[KUDr]

You are not using HW buffer for the whole scene...

Currently in TE i have 16k of possible tiles precompiled (takes about 1 megabyte, yest, that is 16k of small buffer objects) and I just skin and render them without rebuilding. The same for all vehicles. Frankly I am just composing the scene from precompiled blocks.

In case of OTTD you just need to create a set of billboards, load them to main video memory and then just move about. All TTD artwork would take approx 5-10 megs of video memory. That is close to nothing. And still you can add particle overlays, atmospheric effects, lightning etc. VooDoo1 would handle that nicely

Yes, this is what i did. And it does work fine with HW acceleration. But it makes 3 FPS in emulation mode (on HW without 3D accel).

And yes, for some OTTD fork it can be fine. Then whole the graphics infrastructure will need significant changes. And it would be difficult to merge further OTTD changes. So new team, new product, different goals, roadmap, etc...
So then again "good, but not for OTTD".

[peter1138]

I cant tell just how often OTTD sends network packets for the vehicle positions and all that

That's because no position information is ever sent over the network; therefore the calculated positions must be exact.

[phil88]

Maybe, if just some things were 3d. I mean, keep the map how it is with it's whole 2d-ish type thing going on, but have the vehicles in 3D, that way, trains will actually tilt when they go up hills and planes won't make sudden turns at 45 degree angles etc.

[Donoteat]

If, in fact, OTTD or a branch of the same is going to be in 3D, the first thing we need are models:

I knocked this up in Blender in about 10-20 minutes, so it isn't very good, but at least shows that TTD style buildings can be 3D.

EDIT: Some people seem to think that making it 3D will ruin it. Provided it is well done with good GUI, it can still work. The current tile scheme could be used quite easily.

EDIT 2: Forget that station, I've made a better one:

[CMircea]

3D would be good if it's used to make the vehicles look realistic, have more cameras, without spoiling it like in 3DTT. IT would be very good if we could set the angle at which we want to see, and rotate the camera as we like.

[Donoteat]

3D games are often ruined by two things:

1. Bad camera angles,
and
2. Bad user interface.

We need to look at some examples of good 3D. For example, Trainz has one of the best camera controls I have ever seen. That could go in 3DOTTD. For graphics, look at Microsoft Train Simulator. It could run smoothly on people's machines in back in the ancient times and still display shadows and overall very good graphics. (although it crashed every two seconds, but that had nothing to do with the engine.) There should be an option to show the land in isometric view, as in Roller Coaster Tycoon 3. For a terrain editor, I doubt we need anything ore complex than we already have; one of the fun things for me always was using square terrain to make realistic elevated and/or sunken city railways. You really can't do that in a freeform track system like in Railroad Tycoon 3.

[PouncingAnt]

I'm going to make the same point I always do on this topic.

Put things into perspective: converting this game into 3D will take so long, that the hardware required to run it will be just as cheap as the cruddiest of today's available computers.

I wouldnt even bother arguing about it, personally.

And another 2 cents: Crappy camera controls are better than no camera controls. Right?

[Psistorm]

well, seeing this discussion, there are right now threeways in which to turn the game into 3D - if at all. so, to compare them here:

- the "full 3d" approach:
this would involve making the terrain, all buildings/trees and vehicles into polygonal 3d-models (think 3DTT/TTT here). the pro would be a free perspective and other perks, like a working shadow system. the cons are most definitely that this will cost quite some performance and will need a decent 3d-card to run smoothly. also the GUI needs to be reworked completely, to take into account the option of a rotateable and tiltable camera (possibly, but it could also be a fixed cam just as well). also, we would need to create a lot of textured low-poly objects. the current objects used for the 32bit graphics are WAY too highpoly and not made to be used realtime. also, the trainstation above looks like a roughly estimated 5-10k polygons, far above the limits for an ingame object (considering we would render a few hundred trees and a few hundred buildings on-screen at most given times)
all in all it might change the game considerably, and require a lot of work. also it would need someone doing some art direction, otherwise wed end up with tons of models that differ in both terms of visual style and polycount. there would have to be one, just one person managing all of this to make sure it works in the end, both the style and also technical problems, aka buses with 5000 polygons or a small tree with a 1024x1024 texture. in short: not the easy way to go. quality realtime 3d takes skill.

- the "hardware accelerated sprite" approach:
basically everything is rendered on 2D-planes and placed onto the screen facing the camera (save for the terrain, probably). this would be faster to render than the current sprite-approach and also would simplify filtering methods when zooming in/out. the polycount per object would be 2 triangles, since all sprites would be mapped on rectangular quad polygons.
so the pros: itd be quick and low on polys, not much of a problem even for low-end GPUs. cons: lots of sprites for dynamic things, such as vehicles.

- the "mixed" approach:
2D scenery and 3d vehicles, this would combine the advantages of both methods IMHO. we would end up with a very low polycount as well as very smoothly animated vehicles. would require some work on the art direction side, such as to monitor the polycount and texture page size of the vehicles.

thats my view on the whole thing. Id favour the 2nd approach imo, since its the best one to keep the graphical style of the game and just gives us some speed benefits in therms of rendering. also, a de-coupling of rendering and game-engine ticks would be useful, so that rendering can be smoother - something Ive personally been hoping for a long time. and with the regular 30ms engine update, motion interpolation/prediction is very reliable, since there are no lags to be expected, thus no "overshooting" of vehicles.