Will try it tommorow (not at home now). Also will try more SDL games , but , i am almost pretty sure, that 95% of our SDL games are compiled without support of .so , and for all those games we need recompiling :( Maybe you know some more games which can works in win/full-screen mode and use libsdl.so ? (because better to test it on all possible games, to make new feature works 100% fine).
@xeron Tested new SDL_os4video.c, and, all works fine ! Giddy can be started as in window mode for begining with no problems ans switch to/from many times, and as well as can be started as full-screen, and swithched to/from win/screen many times with no problems ! Yeah ! So, for now, any new SDL-GL programm can be windowed even just by adding support for SDL_WM_ToggleFullscreen() / SDL_ToggleFullscreen(),
PS. Btw, how can i strip lbSDL.so ? If i just do: strip libSDL-1.2.so, then it give me DSIs and crashes on start.
PS2. Tested many SDL-GL games which cant work before in window mode, and, new libSDL.so does not help of course, because they all not use .SO as expected. For example these games as: Xmoto, The Goonies, ChromiumBSU, PR-DOOM_gl, Neverball/NeverPutt, SDL-ball - the all was compiled without usage of .SO, and because of it we can only wait when somebody will recompile all those games with new features..
kas1e wrote: PS. Btw, how can i strip lbSDL.so ? If i just do: strip libSDL-1.2.so, then it give me DSIs and crashes on start.
You can't. Forget I mentioned it.
Quote:
compiled without usage of .SO, and because of it we can only wait when somebody will recompile all those games with new features..
Yeah. I hope to put up a new build of SDL_Image soon as a shared object. I think SDL_Mixer is already available. Once those three are ready, i'm sure Spot can help out with a few ports
Check that screenshot :) Sources of chroium looks strange, on gmake say: gmake: *** No rule to make target `glpng.pro', needed by `Makefile'. Stop. Configure also does not works..
@Xeron I noticed a bug realted to new feature (imho). It happenes not all the time, but offten, when you exit from the windowed mode. It was happenes with Giddy3, and happenes now for TheGoonies. StackTrace: Quote:
That suggestion comes from SpotUP, so he should be able to provide more details. Basically, some attempted SDL + GL ports are failing because they can't get a valid screen mode, when the resolutions being requested exist. I have no idea why, but it's a serious shortcoming, so I put it on the list.
this is not a problem on the SDL but in the game itself. 90% of Games doesn't check the correct return value when they ask for video modes. -1 means ALL video modes are available. But the games doesn't use a fallback list mode and so they can't get a valid screen mode.
Can you please have a look at that SDL_FreeSurface bug ? I think you just forget add on exit something, which you can easy/fast fix. (bug happenes for all windowed opengl/sdl apps, so i think its better adress to you than to Xeron) :)
For now i fix it just by commented out it. Its ugly hack of course, because i do not understand what i do, and why it works now. I just comment that 935 line in SDL_surface.c , recompile new version, and giddy3 - works fine. Also for now recompiling statically with new "hackish-ugly" library, and The Goonies and NeverBall works fine too. But that that all imho wrong for future :)
Yeah, you've almost certainly broken non-GL apps in some circumstances. I'm 99.9999% sure that the bug is not that actual piece of code, and that code simply shouldn't be called in the OpenGL case. I expect it'll be very easy for me to fix as soon as i find 5 minutes in front of the A1 to look at it.
i would but here at home my gcc 4.2.4 crash when try to compile a file on OS4 while my darwin cross compiler is the 4.2.3 version and so it could be bugged when so files are compiled.. i need a 4.2.4 (or higher) for darwin or you have to wait when i go at work
Hi @afxgroup Andrea, I'm a fanatic of SDLBasic that you ported to OS4 sometime ago (2006?). Since OS4 Update1 that program runs horribly. Even using Peter Gordon's updates has no effect. The big killer of the system is the mouse. The mouse locks up the system so bad, I have to reset by tower switch. The other big killer is the video frames/sec. The new screen routines of Update1 have severly slowed down the SDLBasic display. After reading through this thread I've concluded that SDLBasic program is really behind the times. Is it possible to that you can do an update SDLBasic? I'd be willing to donate towards that! Because of SDLBasic problems, I don't use Update1.
Hi @Raziel Man, you are genius You and all the others working on the dream OS Thank you so much .
Yes, it fix the problem !:) Tryed giddy3(.so) and the_gonies / never ball / never putt (static): to/from window/fullscreen /exit at any stage => all works fine and without any silly DSIs.
@everyone Screenshot of 3 games at time in action, in window-ogl mode (at last)
@SpotUP Imho its time to say about any other problems in SDL :)
@AfxGroup Quote:
this is not a problem on the SDL but in the game itself. 90% of Games doesn't check the correct return value when they ask for video modes. -1 means ALL video modes are available. But the games doesn't use a fallback list mode and so they can't get a valid screen mode.
Not sure that i understand very well your answer, but, imho, if the same games works fine in that list_mode_terms on other Oses like linux/win32, then, even if it problem of games, we need to make workoround in the SDL for allow games works the same as on other oses, to make live of porters easy (imho).
Edited by kas1e on 2010/3/28 9:45:21 Edited by kas1e on 2010/3/28 9:46:04
Not sure that i understand very well your answer, but, imho, if the same games works fine in that list_mode_terms on other Oses like linux/win32, then, even if it problem of games, we need to make workoround in the SDL for allow games works the same as on other oses, to make live of porters easy (imho).
because on Linux/win not all video modes are available like on os4. We can open a screen with any resolution without problems while on Windows (for examples) video modes are that one available in the system (based on the video card and the monitor). On OS4 you can open a screen like 666x873 without problems. look at
and look at result value. If you see that games that gave you a no modes available you will see that -1 is not handled correctly. I know it very well since i've ported a lot of games with this problem.
@afxgroup Aha, understand now .. So, porters need to do some code anyway then.. Btw, Huno make a fast test-exe of his PrBoom OGL port with that nasty feature which you and xeron added, check this out :)
i've used two test files. one is testgl changed to allow the loading of dynamic functions and testdyngl. This second file doesn't show nothing on the screen but doesn't crash. i've also test it statically and the result isi the same. so the problem is on minigl. of course on window it wrorks correctly.
As i understand you have some problems related to minigl ? So if you can explain it more deeply here, i think (hope) Hans will help with that.
ps. Also i see that you build UFOAI and it works fine ? Can you upload it somethere for test ?:) I check screenshots on ufoai.sourceforge.net, they looks pretty neat.
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
