or we could add the functionality as a patch which runs ontop of the executable - this way we would finally have this OTTP some users keep talking about
PouncingAnt wrote:Most patches have an on/off switch. Why not just use that?
Because in order for a lot of the projects/suggestions to work well they have to be in combination with other projects/suggestions. For example:
- balancing the economy would benefit greatly from changing the scales of things.
- As mentioned before the 32bit project would benefit from changing the scale of things
- But you cant change the scale of things without new graphics and reworking the economy.
I thought I'd defend myself on this point (I know I don't need to but I'm bored, hey)
who says we have to make the new graphics mandatory? Or that rescaling would be mandatory? You could still have these things managed by patch settings. its just a matter of if(whatever==true) {badabing!};
Of course thats a simplification, but its still *possible* to keep most noticeable things on switches, y'know.
The OTTD 2 project already exists and is called Transport (Freaking) Empire
With the changes required to make OTTD a game up to current technical standards (graphics wise at least) you'd just be better off with a new game anyway.
PouncingAnt wrote:Most patches have an on/off switch. Why not just use that?
Because in order for a lot of the projects/suggestions to work well they have to be in combination with other projects/suggestions. For example:
- balancing the economy would benefit greatly from changing the scales of things.
- As mentioned before the 32bit project would benefit from changing the scale of things
- But you cant change the scale of things without new graphics and reworking the economy.
I thought I'd defend myself on this point (I know I don't need to but I'm bored, hey)
who says we have to make the new graphics mandatory? Or that rescaling would be mandatory? You could still have these things managed by patch settings. its just a matter of if(whatever==true) {badabing!};
Of course thats a simplification, but its still *possible* to keep most noticeable things on switches, y'know.
as the 32 bpp stuff is planned now, that will not work, because the 32 bpp version plans to use different (more correct) scaling between buildins/trains/trucks/etc. So no, the 32 bpp version as currently planned can not be a switch.
robotboy wrote:why? What if its set before the game is started so before the map is generated?
Yes, that would be possible, with a lot of work. But when I look at the current requirements for the 32 bpp version and the amount of coding that would involve, I'm afraid it would be such an extensive change to the code base that it would practically be like having two complete game versions in one program and toggling between them depending on the setting.
The changes would involve more than what I did for the Challenge Spinoff, and that already had no chance of ever making it in the trunk because it changed too much for just one setting.
Imho this is a lousy design then. Just upscaling the dimensions before output by a certain factor (i.e. 4 from 16 to 256) should be easily possible. If this is beautiful with the 256x256 graphics (since the smallest step would be four pixels) is a completely different question.
prissi wrote:Imho this is a lousy design then. Just upscaling the dimensions before output by a certain factor (i.e. 4 from 16 to 256) should be easily possible. If this is beautiful with the 256x256 graphics (since the smallest step would be four pixels) is a completely different question.
calling someone elses work lousy is not humble
The design is currently being worked on by mostly graphics artists, so perhaps it is not ideal from a programmer's standpoint. But this is going completely offtopic... Discussion about this should be in a separate thread, perhaps in the graphics forum.
Sorry, I was too harsh with lousy. I rephrase: assuming a non fixed tilesize should be possible even with the current codebase but just changing the sprite display routines (i.e. changing dimensions just before output). If the graphics size penetrates the game logic, this I personally would consider a bad design. But this is really going offtopic.
mexicoshanty wrote:
Because in order for a lot of the projects/suggestions to work well they have to be in combination with other projects/suggestions. For example:
- balancing the economy would benefit greatly from changing the scales of things.
- As mentioned before the 32bit project would benefit from changing the scale of things
- But you cant change the scale of things without new graphics and reworking the economy.
I thought I'd defend myself on this point (I know I don't need to but I'm bored, hey)
who says we have to make the new graphics mandatory? Or that rescaling would be mandatory? You could still have these things managed by patch settings. its just a matter of if(whatever==true) {badabing!};
Of course thats a simplification, but its still *possible* to keep most noticeable things on switches, y'know.
as the 32 bpp stuff is planned now, that will not work, because the 32 bpp version plans to use different (more correct) scaling between buildins/trains/trucks/etc. So no, the 32 bpp version as currently planned can not be a switch.
Well OK there are some things that aren't configurable I'll change my statement:
but its still *possible* to keep most noticeable things on switches, y'know.
to:
but its still possible to keep *most* noticeable things on switches, y'know.
I don't think it's a good idea to split the development. We will always be able to download the traditional openttd 0.5.1 or 0.6 when openttd 0.7 with 32bit graphics is out.
I slightly disagree... however I don't think development should be "forked" so to speak.
I think at some point there should be a branch in the code to form an "OpenTTD Classic 1.0" - a game which solely focuses on being true to the old TTD/TTDpatch in terms of the graphics and gameplay, whilst further OpenTTD development continues unabated. Anything which changes the gameplay from the classic OpenTTD should be held off until then. Ideally, once branched, changes to some parts of OpenTTD could be backported (i.e. AI work) to the classic version, and otherwise OpenTTD Classic would then simply be a bugfix / maintainence only development branch.
That would give license to the team to be more experimental with OpenTTD because people could just be directed to OpenTTD Classic if they want a stable true-to-TTD/TTDpatch game.
However to just point them to "previous versions" of OpenTTD would be a marketing disaster. You need to explicitly differentiate between the two.