boekabart wrote:Hmm, how are custom tracks rendered differently? These overlays are drawn after tracks, before overhead wires IIRC.
Re the pink thingies: what blitter are you using?
Look at that, a boekabart! How have you been? It has been a while
welcome back (I hope? )
I've been good and busy (house, work, kids'n'stuff). Re Back: well.. someone reactivated this thread so I came back... I haven't been here or in a game of OTTD for a long time, don't really have much time for it lately. I might start following the forums a bit more again now that I'm logged on anyway
Yes and no. On non-OSX, you start in a 8bpp blitter, unless you load a 32bpp NewGRF, then you switch to a 32bpp blitter. So if and only if you don't have OSX and have no 32bpp NewGRFs actively loaded, you use the 8bpp blitter. Otherwise the 32bpp blitter.
The only thing necessary for the triumph of evil is for good men to do nothing.
TrueBrain wrote:Yes and no. On non-OSX, you start in a 8bpp blitter, unless you load a 32bpp NewGRF, then you switch to a 32bpp blitter. So if and only if you don't have OSX and have no 32bpp NewGRFs actively loaded, you use the 8bpp blitter. Otherwise the 32bpp blitter.
Error occured playing openttd-hardpack-0.7.142 win32 version under windows 7, without any newgrf loaded. So I suppose , my blitter is 8bpp.
TrueBrain wrote:Yes and no. On non-OSX, you start in a 8bpp blitter, unless you load a 32bpp NewGRF, then you switch to a 32bpp blitter. So if and only if you don't have OSX and have no 32bpp NewGRFs actively loaded, you use the 8bpp blitter. Otherwise the 32bpp blitter.
Error occured playing openttd-hardpack-0.7.142 win32 version under windows 7, without any newgrf loaded. So I suppose , my blitter is 8bpp.
Likely to be a "wrong palette" problem then (oldtracks.grf is used internally and game might use the wrong palette when loading it, i.e. don't convert Win->Dos while it's needed or do convert Win->Dos while it's not needed for this case).
Also it could be a bug in 32bpp-anim-aa blitter - extremely unlikely as the game isn't expected ever to auto-select it but who knows. Thus I'd like to ask you to edit up your openttd.cfg and play a bit with a blitter used. Try using "32bpp-anim" or "32bpp-optimized" and check if the problem is gone with it. Then quit the game and edit cfg to select "32bpp-anim-aa" blitter and give it a try. Would the problem persist with it?
LeXa2 wrote:Also it could be a bug in 32bpp-anim-aa blitter - extremely unlikely as the game isn't expected ever to auto-select it but who knows. Thus I'd like to ask you to edit up your openttd.cfg and play a bit with a blitter used. Try using "32bpp-anim" or "32bpp-optimized" and check if the problem is gone with it. Then quit the game and edit cfg to select "32bpp-anim-aa" blitter and give it a try. Would the problem persist with it?
I have tried with "32bpp-anim", "32bpp-optimized" and "32bpp-anim-aa". No changes, pink pixels are still visible.
If you use opengfx, you must convert the oldtrack.grf to dos palette. or you do it properly and have the .obg handle this stuff... (to do that you have to add the sprites to openttd.grf and ogfx_extra.grf)
Eddi wrote:or you do it properly and have the .obg handle this stuff... (to do that you have to add the sprites to openttd.grf and ogfx_extra.grf)
While this would be the less breaking solution, setting _palette_remap_grf appropriately before calling LoadGrfFile() would do the trick as well. Updating a patch is more than just fiddling until it applies without conflict.
Apologies for the thread necromancy, but I've always liked the idea of this and tried to get it working today without success.
Can anybody confirm if it still works with the latest version of openTTD and which files to actually use? Think I may have gotten a bit confused as there ares o many versions attached around here.
It's working in OpenTTD Spring Patch Pack 2013 v2.0.103, which is based on OpenTTD r25965, which was released on November 11, 2013. Latest release in trunk is r26288, released on January 30, 2014. It is possible that something in trunk has changed which has broken this patch.
Tested this with 1.4.0 and it worked fine. It just cannot be used with that "stuck trains" patch since they use the same byte to store their rail_map data. Aside from that the latest patch file in this thread works perfectly fine.
Hi all, one question. Please, if I want to use this grf file that I inserted to folder with newgrf files but this file is not in list of newgrf in game. Don't you know why?
I would like to play with this graphic. Thx to all. : o )
y2000rtc wrote:Hi all, one question. Please, if I want to use this grf file that I inserted to folder with newgrf files but this file is not in list of newgrf in game. Don't you know why?
I would like to play with this graphic. Thx to all. : o )
You're in the development forum, the area where changes to the OpenTTD program itself are discussed.
In this case, it is a combination of a change in OpenTTD itself by means of a patch (http://wiki.openttd.org/Patches for a discussion what they are, and what to do with them), and a NewGRF. To play with this extension you need to do both. Only installing the NewGRF won't work.
Being a retired OpenTTD developer does not mean I know what I am doing.