I have already seen a kind of "rebinding texture that does not exist" bug in an other program (Huno's quake 3 ?) with the Wazp3D debugger : seems so be a MiniGL bug that try to set up texturing (W3D_BindTexture + W3D_SetTextureBlendTags) even if the textures have beeen freed
I can't fix the other one, it looks like Warp3D/MiniGL and SDL's on-the-fly fullscreen switching don't play nice together. I'll disable that, e.g. you'll have to restart the game to switch to fullscreen.
Yep, even with restart it will be ok. Seems you meet with some other bug in ogl+sdl combo which need somehow to nail down and report.. but for sure it happens not all the time: in bunch of other sdl+ogl ports i do, i can do switch between window and full-screen in realtime. Through i of course do not know details, as it was mostly ports to make it works and crashes free ) , only know that realtime switch in sdl/gl can works in most conditions.
@kas1e There is no mystery here. The fullscreen/window switches involve tearing down the old window and GL context, so the texture get flushed as well. This doesn't happen in games where the whole graphics subsystem is restarted, and the textures are reloaded "manually".
This is just like television, only you can see much further.
A slightly more interesting screenshot: http://s1064.photobucket.com/user/BSz ... /AmigaOS4/trans2.jpg.html I doesn't download anything yet, because a function clogs the event handler in libtransmission. (On the screenshot I have no connection to the router, before someone points it out :) )
This is just like television, only you can see much further.
Oh boy, where should I begin... It looks like I picked the wrong game for my first port. RTTR bots have a nasty bug which sometimes corrupts the heap. Problems like these are pretty time consuming to track down, and right now I'm busy with university assignments and exams. Still, I didn't want to look like some wanker, who accepts a machine donation for nothing. I was in a desperate rush to find something I can port quickly, and will most likely be stable. In the end I chose Odamex, which is a multiplayer-oriented Doom port. It comes with a fully functional server browser (except for the file chooser). I know, it's an FPS, but had to improvise
1 - Odamex need libsmpeg.so, if you are refactoring the final archive please include it
2 - If no real wad are found Odamex will be opened but the screen remain black, i solve the issue copying a basic DOOM.wad, but maybe it's shouldn't react as is, but just skip it instead
3 - I got a DSI crash on the ag-odalaunch, see below:
Quote:
Crash log for task "ag-odalaunch" Generated by GrimReaper 53.16 Crash occured in module ag-odalaunch at address 0x6F8CE31C Type of crash: DSI (Data Storage Interrupt) exception
Work fine with the Xe 933 too ... tested with Doom2 . Doom1 and free doom... Only problem i have couple of time a DSI after closing the Application....
I didn't get any DSIs, so you have to give me the exact steps on how to reproduce them. I'll delete libsmpeg.so from my SDK, the linker always links to it instead of the static library.
This is just like television, only you can see much further.
@kas1e There is no mystery here. The fullscreen/window switches involve tearing down the old window and GL context, so the texture get flushed as well. This doesn't happen in games where the whole graphics subsystem is restarted, and the textures are reloaded "manually".
That's most likely an SDL bug, because GLUT based applications can switch between windowed mode and full-screen on the fly.
@Hans RTTR doesn't use GLUT at all, only SDL. The problem is with MiniGL + the fullscreen switching indeed, but I have no means of fixing that from the game side, I can only disable it.
This is just like television, only you can see much further.
I know. I was pointing out that it's probably SDL's fault because GLUT can do fullscreen switching without any issue.
Quote:
The problem is with MiniGL + the fullscreen switching indeed
Like I said, the problem is most likely with SDL. MiniGL can do fullscreen switching, as is demonstrated by its GLUT implementation. The switching is tricky for SDL, because SDL insists on managing the screen/window itself, whereas GLUT lets MiniGL handle that.
It wouldn't surprise me if SDL is destroying and recreating the OpenGL context, which would kill all of the textures.
EDIT: I just had a look at os4video_SetVideoMode() in SDL_os4video.c, and it really is destroying and recreating the context.
Anyway, this is something that should be fixed in SDL.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
