Transport Tycoon Forums

hey coders. whast the deal with shadows, can we have shadows that go over to other tiles? and how does the computer deal with them, are they just 2d projections, and need to be as a seperate image file?

Alltaken

Yes, we could use a sprite which represents the shadow using the alpha channel. However, there will be no distortion when the shadow falls on a slope.

Celestar

Alltaken, your additions look great! (and it makes my puny little house look like a small shed ) There are some issues given your ideas on reflections. Another issue will be shadows, but I'll get to that later.

Defintions

• Vector Is a mathematical construct which indicates a certain direction in space. An objects speed can be indicated by a vector showing the relative velocities in x, y and z.

• Normal The normal of a point on a surface is a vector which points completely away from the surface. For example, the normal of the xy-plane points upwards along the z-axis.

The problem with making a colourcode for each normal of a surface with reflection is that it does not take in account the height or depth (depending on how you look at it). Lets place a simple cube on one of the tiles.

To make matters easier to talk about, let the x-axis of this cube be the ne-sw direction and the y-axis the ne-se direction. The z-axis is just the normal-vector of the ground. Point (0, 0, 0) is thus the bottom-northern corner of the cube.

Now, in our projection of this cube the point on the 'sprite' plane we draw for (0, 0, 0) could also be the point we would draw for (1, 1, 1). There is nothing that would tell us something about the depth of this specific point. Lets now consider the plane given by the points (0,1,0), (0,1,1), (1,1,0), (1,1,1). This is the eastern plane of the cube, standing upwards. According to the specification you gave, this plane should get a colourcode to signify that the normal of the plane is in the direction of the y-axis. Now, if we want to draw the pixel for point (1, 1, 1) (which is on this plane) we need to consider points of the neighboring tile. However, at what height? There is nothing that tells us wether we should draw the bottom part or the top part. Points (1, 1, 1) and (0, 0, 0) were not discernable, remember?

As a possible solution one could use a set of discrete values, say, from 0-255 to indicate the height of each pixel in the beforementioned plane. With this height, we can deduce that the pixel we draw for (1, 1, 1) is indeed (1, 1, 1). With the colourcode we can deduce that the normal of this pixel is towards the y-axis and thus we can draw a perfect reflection.

This however poses two other problems: first of all, it won't allow to make reflections higher than 255 (unless we use more bits for the height, which is not advicable). The solution to this problem is easy. We know that the depth of each pixel cannot be more than 32 (unless we allow overhangs). Thus, we do not encode height, but encode the depth and from there calculate the (x, y, z) values.

If this is all giberish for you: imagine a simple skyscraper with all glass windows. The designer had the urge to place all the windows in a sort of checker-like pattern. The 'black' windows being deeper into the building than the 'white' ones. Now, it is easy to see that the image of the projection will also be distorted.

Another big problem is speed: all the tiles now make each other 'dirty' when something happens to them. For example, when a bus drives before a building with reflections. Everytime the bus moves, the building (or part thereof) needs to be redrawn. Experience should show how well this can be tackled.

Now the problem of shadows. In essence, shadows can only be drawn on simple surfaces on the xy-plane. When we get curves, stuff will mess up. Also, there should be a seperate shadow layer in the drawing routines to handle this stuff. It would more or less go like:

1. Draw ground tiles, water tiles, roads, railroads and building foundations
2. Draw shadows of buildings and moving objects on ground tiles.
3. Draw reflections of buildings and moving objects on water tiles
4. Draw buildings and moving objects
5. Draw reflections of tiles, shadows, buildings and objects on buildings and objects.

However, it would look very strange when a moving object passes a shadow. We could colourize the moving object down when it passes a shadow, but projecting a real shadow is impossible (or nearly impossible).

All of this should be thought of very hard. If any of you know a game-developer, ask him what he or she thinks. It's hard but not impossible what we want to do.

Ok, enough for now, need to go to work

The game is not 3D. Implementing things like this might require a total rewrite of the graphics system.

Celestar

Celestar wrote:The game is not 3D. Implementing things like this might require a total rewrite of the graphics system.

Celestar

I agree, never said something about making the graphics engine 3D. But we're talking about a 2-and-a-half-3D environment. It appears to have the looks of '3D' while it is just 2D. Nothing I said will imply that the game becomes a true 3D game. Just looking for possible solutions to problems in maintining a 2D model.

A complete rewrite is something different to talk about. I guess that for 32-bit rgba, 64 pixels width tiles and smooth curves A LOT need to be rewritten. We're not making definitive plans here but researching concepts. As a programmer, I'm willing to take responsibility for adjusting the OpenTTD code (as long as I can find enough time).

They are made fron TTD's. They are not new

Oh, man, that's sick. Are you all going to bash and shout at everyone who's got one pixel from TTD's original sprite?
The face is new, just based on TT original sprite.

Oh, who cares about name?
If one call it "super graphics" if you can call it "new graphics", it will be enought to base on TT graphics?

George wrote:

mdhowe wrote:--Road vehicles:
----Buses: Tropic Set by uzurpator (Don't have permission), xUSSR Set by Zoom (Don't have permission), George's long vehicles (Have permission)

They are fast drawn from zero. But they have to be improved then, because they use some elements of Original TTD graphics. Lets see in details.
1) Ore, coal, grain, wood were taken from MB's cargo set (with permission of cause). If MB used default - they have to be replaced then
2) Volvo FH16 Goods Van (Tarpaulin) has to be updated with new platform, because it uses TTD fruit van graphics
3) McTrucks can not be used at all, because they use default graphics a lot
4) Scania GA 4x2 Goods Van (Tarpaulin) and Scania GA 4x2 Rubber Truck have to be updated with new platform, because they use TTD fruit van graphics

2) and 4) are fixed now

MeusH wrote:

They are made fron TTD's. They are not new

Oh, man, that's sick. Are you all going to bash and shout at everyone who's got one pixel from TTD's original sprite?

I made this GRF, so I CAN say it.

MeusH wrote:The face is new, just based on TT original sprite.

No, it is fast totaly unchanged. If you don't know about mars landscape for TTO, it does not mean that it was not created by microprose.

MeusH wrote:Oh, who cares about name? If one call it "super graphics" if you can call it "new graphics", it will be enought to base on TT graphics?

The topic is "TOTAl graphics REPLACEMENT discussion". NOT IMPROVING, NOT RECOLOURING, BUT REPLACEMENT! That means only absolutly new graphics can be used for that.

I know what mars landscape is and I've played it really long time, so don't make me dumb.

Oh, remember about airports, city, inter and metro one. Total new...

MeusH wrote:I know what mars landscape is and I've played it really long time, so don't make me dumb.

Oh, remember about airports, city, inter and metro one. Total new...

They are not new. Just the layout is new, but if you look closely they use absolutely the same graphics as the old ones, just perhaps in different combos.

I know
Personally, I like them very much, and I think they are best. They just fit.
No need to change that, but, uhh... someone really wants that

MeusH wrote:I know
Personally, I like them very much, and I think they are best. They just fit.
No need to change that, but, uhh... someone really wants that

It's because now you need the old TTD game (because of the graphics) to be able to play OTTD. Should OTTD be stand-alone game, it needs its own graphics - you cannot simply copy graphics from TTD because of copyright.

Okay. If you mean OTTD without TTD, I understand. Good.

So how about nfo's and code?
I have suggestion: Rename planes to their original TT names, like Boening (instead of Darwin, I think), Concorde, Junkers ju 52... please!

Ok I will have a bit of free time tommorow (and maybe later tonight - will probably be nackered after work) so I will see what I can do with the GUI graphics.

In my opinion 24bit graphics are a bit wasteful. The human eye can only see about 7million colours, and not many monitors can even support this many colours. 16bit graphics may be a bit low so is there anything inbetween?

lucaspiller. whats wrong with 24 bit Graphics. i say just do it LOL. if things are saved as PNG format they can be compressed into a palleted format if you choose. so you can get the option of 24 bit grpahics, but if the colours are few or limited in range, then you can index it no worries. but in another section of the GUI where more colours are needed, then you can leave it un indexed. things like that might help out without comprimising your quality.

Alltaken

lucaspiller wrote:In my opinion 24bit graphics are a bit wasteful. The human eye can only see about 7million colours, and not many monitors can even support this many colours.

Ever heard of banding?

Alltaken: Suppose I might as well, its not going to make much of a difference in size.

wolf: If the human eye can only see half the number of colours that can be displayed - and most monitors can't even support that many - wouldn't you get banding anyway, even at 24bit?

From what I know, human eye can see much more than any monitor can display. And at 24 bit there won't be any visible banding, I was referring to your suggestion of using less than 24 bits per pixel.

I would say that 24bpp is actually a very good option. For two reasons:

The first is the fact that most videocard drivers are displaying 24bpp anyways (I believe this is called "TrueColor" under Windows). It's very easy, since it contains 8 bits for red, 8 bits for green and 8 bits for blue. Most computers calculate with bytes and a byte is exactly 8 bits. Using less than 8 bits requires a lot of recalculations. 'Downsizing' to 16 bpp (I believe that is 5 bits for red and green each and 6 bits for blue) can be done quite fast by just choping off the least significant bits.

The second reason is that 24 bpp plus 8 bits for alpha transparancy is exactly 32 bits for each pixel, which also calculates well.

About the banding: yes, you'll see banding even in 24 bits per pixel, but only in very extreme cases. With small sprites and a lot of details, this will not be visible at all.

Most monitors can't display that many colours though - just because your graphics card can doesn't mean your monitor can. Anyway I am not really bothered too much, as long as the game doesn't end up being a few GB in size....

I have sort of done some graphics for the GUI buttons and they look ok-ish. I have made them 28x28 (slightly bigger than the icons up the top of the forums) because that should just about fit on a 800x600 resolution. If anyone is using anything less than this they are screwed, I have tried it on my 17" 1280x1024 monitor (^_^) and it doesn't look too bad - I think I may need to change the colours though. I shouldn't think many people are still using 640x480, but if they are, ummm, hmmm, eeek...