Seasons (changing snowline, trees, fields)

[Dextro]

ok this looks like it's working great but I don't know why the options keep getting turned off on their own

I use the fastfoward key and a few time after when I go check the options they are disabled

I believe it might either have something to do with the end of the night OR a newspaper showing up but I'll have to check a bit more... The fact is the options get disabled on their own

But great work Hope someday someone will be able to tackle the darkened gui thing...

[Nanaki13]

Would be nice if the buildings and shores were changed to ones with snow as well.
And i confirm that the options turn themselves off, altough i can't tell when.

[bobingabout]

a simple way to fix the GUI issue would be to use a different pallete for GUIs than for the ingame objects, however, although there shouldn't be a problem doing this in a windowed mode, it would be hard to do in a full screen mode, because the game is fully 256 colours. would need a small game colour hack to make it use 24 bit colours(called 32 on the graphics cards produced after about 1995, although the last 8 bits are simply not used.) but still use only a 256 colour pallete.

[prissi]

THus I would suggest to do this, when there is the new 24Bit color engine. Actually, if you run SDL in 24mode, you can also exclude some update areas and draw the GUI with a different palette. But imho this is a waste of time, since the work will become obsolete anyway when 24 Bit is going.

(Although from my Simutrans experience, I still suggest 16 Bit for graphics, since this reduces the main memory bandwidth demands drastically.)

[bobingabout]

well, you could go 16 bit. but would we use 15bit 555 mode or 16bit 565 mode? plus its likely it would distort some colours, because doesn't every colour in the 256 colour pallate get assigned a 24bit RGB value?

[Nanaki13]

8b color is a subset of 24b, 16b is not.

[CobraA1]

(called 32 on the graphics cards produced after about 1995, although the last 8 bits are simply not used.)

I believe it is often used for the alpha channel.

(Although from my Simutrans experience, I still suggest 16 Bit for graphics, since this reduces the main memory bandwidth demands drastically.)

Depends on what the video card uses natively. Today's cards are optimized for 32 or more bits, and should be able to handle the bandwidth without problems. Older cards may have some troubles, though.

Going from 8 bit to 24/32 bit will actually be easier than going to 16 bit, as Nanaki13 is correct: 8 bit is actually a subset of 24 bit, as each color is a 24 bit RGB value. Going to 16 bit may distort colors a bit.

[Aegir]

Okay, I have some suggestions for seasons, an option to, instead of having snow coming down apon everything (Make it an option, also with two fields, snow height outside of winter, snow height in winter), how about a similar pallette shift (Damn, I cant believe my idea *worked*!), with greyer, duller colours in winter/autumn, and brighter cheerful colours in spring/summer?

Because personally, I play Arctic for snow, and Temperate for, well, temperate. The duller colours would also simulate what it looks like when a cloudy, rainny, groggy storm comes down (Seeing lots of those in Australia lately, no snow (Damn), but lots of cold, grey dreary weather).

Great work so far, you've well and truly kindled my interest in OTTD .

[bobingabout]

older cards would simply have to run at a slightly lower resolution to get 24bit. for example, a 1 meg card can run 256 colours at 1024x768, but 24 bit would require changing res to 800x600 or even 640x480... however, get a 4 meg card, and that can happily run 24/32 bit colour at 1024x768.

[prissi]

Aegir:
There are unlimited possibilites. There could be more bluish night in winter, a certain reedening during sunrise. It would be also very easy to use more than four stages or a monthly pallette. This could be even in the config files.

Also the artic tree obey summer and winter. The 12 temperate trees do not. Sice at least five of them are nearly identical to artic one, there could be more seasons or more winter trees. It would be fun to try this with the japanese trees.

I though about those, but was too lazy. And digging through the UI code is never fun but so much less with OTTD

(Since I am head developer of Simutrans at the moment I rarely play OTTD because it is no challenge: cities growth too easy, braindead passengers, use a coal line and make more many than you can spend, ... you certainly know.)


About 32Bit/16Bit matter, or which bandwidth matters:

32Bit need 4x the bandwidth. First time to copy to backbuffer, second time to copy to the screen. And even though AGP has in priciply a hugh memory bandwidth, writing into an AGP card by CPU is sloooow. It is about 4-10 times slower than a main memory cache miss.

Perhaps you should think about what memory bandwidth is needed. 32*64+8=16k, some transparent pixel compression => 8k per image. The game has 10000 of them => 80 MB, ok.

1024*768*32/8=3MB. Desireable 25 frames per second + double refresh (as written above) => 25*3*2=150 MB/s. This does not sound too bad for a computer board whose theoretical limit is around 800MB/s or higher. But unfourtunately about half of these are cache misses: when an image is drawn into the back buffer. And the maximum bandwidth for unbuffered main memory access is around 50MB/s and has not increased much in the last years.

(Usually 16Bytes are loaded, depends very much on memory architechture and organisation. There is a program from german c't, where you can also check the memory access speed beyond level 2 caches.)

Anyhow, the above calculation does not take into account the use of a list of regions, which do not need an update and so on. So with clever programming, the actual amount might be only lower.

In Simutrans, which uses such strategy, once I put the back buffer also on the video card. The advantage of faster switching between buffer was completely aten up by the bandwidth increase. It ran about 4x slower than in main memory. Copying 16Bit data to a 32Bit screen takes some time (1ms/frame) but is done in hardware on a decent card. Apparently it took less time than it took to copy the higher amount of memory.

And 16Bit still make the use of a palette possible. This way a darkening/company color replace of images could be calculated very fast.

The downside is, that of course some color transitions will look less smooth. But comparing this with the current OTTD graphics ...

[Aegir]

Hmm, all good points. Actually, controlling colours from a config file is a neat idea, thats whats used in Morrowind for its lighting effects for various times etc...

Just gotta prod you to make it .

And say, you wouldnt happen to know any ASM would you? Nah, just kidding. Great work man, great work.

[CobraA1]

older cards would simply have to run at a slightly lower resolution to get 24bit. for example, a 1 meg card can run 256 colours at 1024x768, but 24 bit would require changing res to 800x600 or even 640x480... however, get a 4 meg card, and that can happily run 24/32 bit colour at 1024x768.

Ouch. Yeah, that's from the early Pentium/486 era.

Perhaps you should think about what memory bandwidth is needed. 32*64+8=16k, some transparent pixel compression => 8k per image. The game has 10000 of them => 80 MB, ok.

(blah blah blah) And the maximum bandwidth for unbuffered main memory access is around 50MB/s and has not increased much in the last years.

Even better: Write them as textures to video memory, draw them using the 3D functions, and you only need to send coordinate updates.

IMHO writing the entire buffer should be avoided, especially on 3D-capable cards. Most modern 2D games are really 3D at heart. If the video card is too old, there should be a fallback to older methods, yes, but that doesn't have to an newer video cards should have to suffer from a problem that can be avoided.

And oh, BTW: That stuff is changing with PCI Express and the nForce4 motherboards . They will have much faster memory, more channels, and faster bus speeds.

[bobingabout]

isn't the NF4 for P4s only?

if i get this right, NF and NF2 are for AMD Socket A, NF3 is for AMD 64bit, and NF4 is for P4s.

why would anyone want a P4 when AMD 64s are far superior?


anyway, back on track.

things i think should be in the making, ok, forget the GUI issue for now, since, not too much can be done about it till we upgrade the game to 15/16/24/32 bit colour.(no need to note the differences...)

1, complete season graphics, and related code.
2, bightness and colour distortion adds for different times of day/year (like redder tints and stuff)
3, Extend the length of a day, to allow true day/night cycles rather than over a month(this extended day/night cycle is another patch idea, nobody seems to be working on it, but the idea is to make a games year last a lot longer, so you can play really long internet games, but i supose it could be used anywhere. for example if a games year took a day, thats like atleast a 3 month game. something inbetween would be required, such as aproximatly 5 years a day or something, or some kind of costom lengthed game day. either way, many things would need tweaking, such as running cost calculations. or profit ammounts.) actually, this should still be a seperate patch, but, would be great if day/night cycles were made to be able to fit in with this.

[CobraA1]

isn't the NF4 for P4s only?

No . This is what I'm planning on getting for my next motherboard:

http://www.tigerdirect.com/applications ... =A455-2112


BTW, tinting and stuff is nice, and works wonderfully on newer computers, but should be optional, as older computers may not like it.

Actually, 256-color tinting is easy and doesn't take much CPU because you just make changes to the pallette. Doing it on higher color depths may be a tad problematic on older hardware, though.

[bobingabout]

cool, NF4 AMD 64, i bet the Socket As still only have NF2 though...

if you can't handle the tinting, you could turn the option off. i'd see 4 options on the patch config menu. Enable Season Cycles, Enable Day/Night transitions, enable coloured tints on transitions, Extend days to last 1 minuite(would 30 times longer, ideal for converting the day/night monthly cycle to a day cycle)(only set from main menu, because it would require changes to running costs and payment amounts, likely other things aswell). it could be possable to add a clock, however, 30 steps is 48 mins every 2 seconds.

[xyz]

Ieeeeeeeeeee

i just love the seasons idea. That is what i call an simulation game!

is it posible to includ this idea in the original OpenTTD??

[bobingabout]

you mean, is it possable to "Merge it into the trunk"?

when its complete, its likely it will get merged, aslong as you can turn it off

[bobingabout]

aparantly, 24/32bit has already been implemented

are you the 1 who would be writing the new 32 bit graphics engine?

no.. that would most likely be me. basic 32 bit support is working, now i'm trying to add sprite-recolour support, and the above mentioned company colour system.

[Aegir]

Prissi, I'm starting some investigation into palette shifts in TTDPatch, I may or may not do a full day/night cycle, but my main goal is my original idea for the subtle season effects.

But I have some questions though, more about how you alter the palettes (Im a bit of a noobie programmer), what type of math did you use to alter the RGB values for each of the 256 colours in each palette? I have some basic ideas, but I'm trying to put them into somthing that works.

Also, could you give me a basic run-down of your code? Im afraid Im even more of a noob to C than I am to ASM (Go figure ), and I'd like to keep a nice caring sharing relationship between OTTD and the Patch (All you people who want to flame me, sod off. You suck.), so everyone helping each other out seems good to me .

Thanks in advance, and, well, love the variable snow height for temperate, well, your work in general, I've had some fun playing with it in OTTD .

Oh, Ill be having a look into the sources aswell for OTTD, might shed some light .

[bobingabout]

are you sure you are a noob?

note the differences.

"Newb", short for "Newbie" meaning someone new.
"Noob" evolved from "N00b" originally evolved from Newb by 1337 users, now meaning (in the most polite way i can think of) a moronic idiot who's main goal is to be annoying.

variation of deffinition depending why you are calling someone a noob.


I'm pretty sure you are a newb, not a noob.


anyway, i wish you luck.