SDL Community Project
BlitzMax Forums/BlitzMax Programming/SDL Community Project
| ||
| Dear community, SDL's renderer represents the opportunity to take Blitzmax to the next level with robust software fallback. While there isn't scale and rotation, it gives you the power to support win, linux and mac cards which either have bad drivers or no 3D capability - and they are far more common than you might think! To this end, I am proposing this thread be made sticky and we work together to create a definitive max 2D rendering solution. Lets get started! The libs - precompiled is most convenient and no GPL issues but modules also welcome: windows: http://www.libsdl.org/release/SDL-1.2.8-win32.zip linux: http://www.libsdl.org/release/SDL-1.2.8-1.i386.rpm mac: http://www.libsdl.org/release/SDL-1.2.8.pkg.tar.gz source in c: http://www.libsdl.org/download-1.2.php Please note these are all precompiled which is easier (unless someone wants to make a mod! Some brave soul...) And we are going for a windows version first. Docs: http://www.libsdl.org/cgi/docwiki.cgi/ Homepage: http://www.libsdl.org/ Source code so far: Contributed by noel cower (this is a very limited bit of source that just shows us some of the keywords, types and constants - perhaps it will help us get started: And here's some alternative code - linking to a DLL but I don't know where to go from here as there isn't much documentation on this (thanks to Sarge on IRC):
global lib = LoadLibraryA("SDL.dll")
Extern...
End Extern...
The goal is to do all the software rendering externs and calls so we can with ease, fall back to SDL software rendering (bmax provides the hardware rendering). To this end we might need SDL's mouse handling if it has it, and the rect class as it's animated surfaces require that. I look forwards to your replies and any help you can give towards this open source blitzmax project. I will share everything I learn from it with you all, so all may benefit. Lets grow blitzmax beyond by working as a team! Your contributions are valued and greatly appreciated. |
| ||
| Software fallback is a great idea. I wonder, though, if it would be easier to just go DirectDraw under DirectX7? |
| ||
| I wonder, though, if it would be easier to just go DirectDraw under DirectX7? It wouldn't. |
| ||
This is the SDL_cpuinfo file, i will do some more later.Extern "win32" 'SDL_cpuinfo Function SDL_HasMMX() = "SDL_HasMMX" Function SDL_HasRDTSC() = "SDL_HasRDTSC" Function SDL_HasMMXExt() = "SDL_HasMMXExt" Function SDL_Has3DNow() = "SDL_Has3DNow" Function SDL_Has3DNowExt() = "SDL_Has3DNowExt" Function SDL_HasSSE() = "SDL_HasSSE" Function SDL_HasSSE2() = "SDL_HasSSE2" Function SDL_HasAltiVec() = "SDL_HasAltiVec" End Extern |
| ||
| This would be great, not sure If I have the skills to help but I'll give you 100% support. |
| ||
| New update from James L Boyd! To easily call DLL's from Blitzmax under windows we can go...
' Load relevant DLLs...
user32 = LoadLibraryA ("user32.dll")
' Check they loaded...
If user32 = 0 Then Print "Failed to open user32.dll"; End
' Create Blitz function prototypes (to match Win32 API parameters)...
Global Info (window, message$z, title$z, flags) "win32"
' Point Blitz functions to DLL functions...
Info = GetProcAddress (user32, "MessageBoxA")
' Call user32's MessageBox...
Info 0, "Hello world!", "Amazing...", 0
BIG thanks to James for pointing this out. All we need to do now is take a really close look at the SDL functions and maybe find out if any need callbacks. For Linux and Mac, there's also precompiled files for SDL, but we don't yet know how they will talk to Blitzmax. Things for us to find out: * list of SDL calls and parameters for DLL calling * how callbacks work with DLLs * how precompiled SDL works with Mac (.pax?) and Linux (see files above) Keep it coming, folks! |
| ||
Remember on mirc,Global Libary=LoadLibraryA( "SDL.dll" ) Global SDL_HasMMX()"win32"=getprocaddress(Libary,"SDL_HasMMX") Print SDL_HasMMX() |
| ||
| Looks like my b spawn of a module is going somewhere. |
| ||
| Please edit for swearing. Thanks so far for everyone's contribution - keep it coming, and only post if you have something constructive to say :) |
| ||
| Hi The code on your first post dont work, Fish. Many Duplicate Identifiers. I think itīs better to go step by step and i have created one sample. - You need the "Win32 Development Libraries" (SDL-devel-1.2.8-mingw32.tar.gz (Mingw32)) from http://www.libsdl.org/download-1.2.php . -Put the "libSDL.dll.a" file in your BlitzMax Lib dir. Now you can run my code. Itīs a bit hard to work without CStructs. First, small sample. Hope i can help Mfg Suco |
| ||
| Many, many thanks Suco-X! this is amazingly well done! I must commend you on the excellent and thoughtful contribution, thank you :) I will examine your code - you are actually using the .a file so this is very interesting! It looks like we can expand this example to cover the entire command set for SDL windows. Do you think this will work cross platform? Once again, thank you for the wonderful contribution. |
| ||
| No Problem, Fish. Ok, next Version. This sample show you how you can load Surface from Pixmaps and i have some more functions added. The Image:  Rename to "asteroid1.png" Sample: This code is very alpha but it works without errors(I Hope ;) ) And yes, it works cross platform. Mfg Suco |
| ||
| Hi Next Update, all SDL functions and 2 helper functions. |
| ||
| I'm at work at the moment but when I return, I will immediately dive in and try this wonderful module out :) Good man! I can't believe you've done this in full. You have my utmost gratitude on behalf of the entire Blitzmax community! Thank you :) You have single-handedly solved all the SDL problems for mac, win and linux - now anyone can make blitzmax games with 100% reliability regardless of target hardware... Thats the gift you've given us :) Finally, I move to ask BRL if they will make SDL module an official part of the Blitzmax modules. |
| ||
| Finally, I move to ask BRL if they will make SDL module an official part of the Blitzmax modules. I second this request. Good work to everyone who worked on this btw :) |
| ||
| Hi I have created a small Gametest with SDL. Please test with Win/Mac/Linux. http://www.sucox.art-fx.org/BlitzPastingv2/uploads/useruploads/rSsjR131877_7005760.zip (code+exe) Mfg Suco |
| ||
| Making it an official part has some probs ... for example they can not include the library itself ... and a module that does not work after downloaded until you download other things isn't that good. Suco: works with XP SP2 no prob with any part :-) |
| ||
| Suco-X - try and use <codebox> instead of <code>. I've edited your posts to use codebox instead. |
| ||
| Sucro-X I downloaded the demo and it did not work at first, but I added the SDL.DLL and then it worked PERFECTLY! very smooth - great test! I imagine that for Mac and linux we need to include the relevent runtimes for each os? |
| ||
| fish: Yepp but official modules for BM are for syncmod. But for SDL you need the sdl.dll or whatever which are 1. not plattform indipendent 2. can not be included due to their license This makes them useless as official BM mod. And no you don't need to include. you need to link to the sdl page as you are not allowed to include it without special permission |
| ||
| windowed mode fails to draw anything or even seem to flip |
| ||
| Cyanide, how do you invoke windowed mode? Can you post code? |
| ||
| Its great work so I don't want to spoil it to anyone. I just want to prevent a "please make it official" hype which would cost many nerves at BRL just for nothing because some people don't read licenses of stuff they use. |
| ||
| TLibSDL.Graphics(800,600,32,false) (last flag, true for fullscreen) edit: thou sdl does the same for me in c++ with windowed mode, so probally my intel pos |
| ||
| Barely informed rambling -- feel free to correct! If you Google around to try and clarify the SDL/LGPL requirements, you'll find there's a lot of confusion (eg. http://www.gamedev.net/community/forums/topic.asp?topic_id=301120&whichpage=1 ), but mostly the debates seem to eventually agree that you basically have to a) distribute the unchanged .dll and LGPL licence with your game, b) make clear reference to the LGPL and c) provide a link to download the SDL source code on your own site. (DISCLAIMER: not legal advice!) Sami Lantingen is the author of SDL, and his thoughts are here: http://www.devolution.com/pipermail/sdl/2000-August/029476.html Only thing is, the current conversion by Suco-X (very nice work!) seems to link statically as far as I can tell, ie. it imports sdl.a (which I think may import other .a libs in turn?), though it still requires the DLL. Maybe I don't fully understand static vs dynamic linking yet, but I'd have thought that using static .a linking wouldn't require the DLL (?). As far as I can tell, you'd have to be linking dynamically (ie. using only the DLL) to fit these conditions. Linking statically means you have to distribute the source or object code to your own programs, as the library is effectively embedded in your program, as opposed to being a separate .dll file. Linking dynamically would mean doing similar to what Sarge suggests for each function... |
| ||
| I'm gonna go with what the author says - include the runtime and a nice little text doc. The rest can get stuffed because it's not strictly statically linking as the DLL is still required. We are also making no changes to the original source. So, for me, DLL and text doc :) |
| ||
| James, When linking to DLL there are two ways to do this. Static Linking or Dynamic Linking. Static Linking is done by creating an import lib from the DLL and linking to that. ie libXXX.a for mingw. The "XXX.dll" is still loaded at runtime but the linker resolving the references via libXXX.a Dynamic Linking is of the form Lib=LoadLibary("xxx.dll") func=GetProcAddress(lib,"Foo") Either way can be used for DLLs however personally although more work Dynamic is better since if the DLL is not on the machine you can programtically error out vs implict your program just crashes saying it cant find some dependent file. Another benfit to Dynamic Linking is if you dont have the libXXXX.a file you can still use the DLL as long as you know the name and paramters of the entry points. Hope this helps understand DLLs and different forms of linking Doug Stastny |
| ||
| Thanks Budman. I know the very basics, but the below is something I wondered about (just because I know that in some cases the .a being linked into the executable is all that's needed, and so assumed that was always the case): Static Linking is done by creating an import lib from the DLL and linking to that. ie libXXX.a for mingw. The "XXX.dll" is still loaded at runtime but the linker resolving the references via libXXX.a ... so knowing this as well is very helpful, thanks. |
| ||
| This is totally awesome! |
| ||
| Indeed. I'm very proud of the community that helped made this happen, and continue to evolve it... it's not finished yet :) |
| ||
| now dont shoot me for asking but I thought SDL was slower then directx and opengl and that it was more or less just an opengl wrapper? am I wrong please explain |
| ||
| You are wrong. It has OGL, DX and Software rendering. Software rendering is why we like it. |
| ||
| so its a wrapper for DX and OGL? |
| ||
| No, the whole point is it doesn't need either (although it can make use of them if available). |
| ||
| Stay tuned folkes, doing a nice demo for Blitzmax which falls back from hardware to software. Got a problem trying to detect if hardware is present. Use the troubleshoot tab on your windows display preferences -> advanced window to disable 3D to test. The problem I'm having is: blitzmax throws an unhandled exception on both DX and OpenGL when not present --- nasty! How do we work around this? Ideally Graphics() should return true or false if it worked or not. |
| ||
| What's the situation with screen resolutions in SDL? Can I have really low ones like 320x200 that aren't supported by modern graphics cards, or will it still fail? |
| ||
| Update: we've fixed the problem with detecting if Graphics modes exist, see this thread. SDL specific questions must be referred to http://www.libsdl.org/ as I can't answer that. But I will try - yeah most modern graphics cards do in actual fact, support really low resolutions like 320x200, however windows XP won't show much below 800x600. Some might not though. You can always do it in a higher resolution like 640x480. I recommend you do... just draw half the size, then scale it up after. There's a version of SDL which does scaling, and you might be able to integrate it with the above code. Why not let us know how you get on? Even better, just draw your sprites in 320x200, then pre-scale them up twice the size. It all depends if you want 320 for the "look" or if you're doing mental pixel stuff... If I can find anything else to help you, I'll post it in this thread. |
| ||
| Is this now complete? ie. Can I use this with Blending modes and rotation/scaling of images? |
| ||
| The initial SDL doesn't support "rotozoom", you need to addon another SDL package for that. If you manage to do it, please contribute it here in respect for the good work done so far to set us off. The link is: http://www.ferzkopp.net/~aschiffler/Software/SDL_gfx-2.0/ So if you manage it (Should be fairly simple based off the above code) please post how in this thread :) tis only fair... |
| ||
| Has anyone made further work on this? I am slowly starting to get to the point in my project in which I'll start adding SDL fallback functionality. I'd hate to do unnecessary double work. :) I think I need to (at least) add LoadAnimImage functionality and try to find a code based solution to making images with per-pixel alpha display OK with SDL. The first one should be no biggie and I hope the second can be solved simply by masking pixels that have "enough" alpha. Has anyone looked yet into SDL_gfx 2.0? |
| ||
| LoadAnimImage functionality is in, but not the way you expect it to be. It uses some sort of rect mechanism to copy the desired frame from a larger image. I would like to see it updated with LoadAnimImage too, but more importantly - has anyone got it working with the mac? You're right - can we do alpha fading with an image with a normal mask? |
| ||
| What happened to this? |
| ||
| Well it all works but it got de-stickied for FMOD, which is why people miss it a lot. Not much mac support. |
| ||
| Does this SDL module allow me to write games for the GP2X (http://www.gp2x.co.uk) in BlitzMax? |
| ||
| Only if gp2x supports pc or mac hardware. |
| ||
| <bump> So is this complete? Russell |
| ||
| Seems to be. |
| ||
| As on http://www.blitzbasic.com/Community/posts.php?topic=57179 I'd like it to be seemlessly integrated as a Max2D module, i.e instead of using SDL dedicated functions to open a display and draw things on it, it should be very cool to just issue a: SetGfxDriver SDLMax2DDriver() and then use usual commands (Graphics, DrawLine, ...) Has anyone began to work on this integration ? |
| ||
| Bump. |
| ||
| We need LoadAnimImage and RotoZoom, anyone? based off 1.2.9 SDL... this is new stuff :) Current problems How to draw offscreen, for example -1 How to draw from cells of images like LoadAnimImage How to Rotate images |
| ||
| Why not have a go at it yourself then? |
| ||
| On some systems that don't have hardware-accelerated support, their OpenGL driver, for example, will do everything in software, anyway. What you're proposing isn't a replacement for the system that is already in place, you are proposing a different graphics library of deliberately software-based rendering. On my ibook for example there is no hardware acceleration, the OpenGL driver is entirely in software. Max2D works totally fine. There is no need for software fallback routines. I don't know if dx is the same. Now, proposing 256-color indexed graphics support would be another matter and that would be useful perhaps, for doing software rendering in. Otherwise I don't see why you need to create your own software fallback. |
| ||
| On my ibook for example there is no hardware acceleration, the OpenGL driver is entirely in software. Max2D works totally fine. There is no need for software fallback routines. The mac is vastly superior at its OpenGL software emulation. I regret to say the pc isn't even close in this regard. I have tried this on the PC, on three different machines. OpenGL in software corrupts really badly before ultimately crashing. It is also garbage in visuals. It also runs at an appalling framerate. This is to be expected, but not this badly... @Chris C, I am trying, I am also asking for help on this. All findings are shared in this thread. Everyone can and will stand to benefit. |
| ||
| Does anyone have the source for the asteroid demo ? www.sucox.art-fx.org/BlitzPastingv2/uploads/useruploads/rSsjR131877_7005760.zip 404... :( |
| ||
| Ahh, I see, I didn't realize it was so bad on the PC. Then it certainly looks like y'all have good reason to seek a software fallback. |
| ||
| Managed to get something going :) Will post what I have if its any good. |
| ||
| Hi everybody, I just tried to create a SDL backend for Max2D, based on SDL 1.2.11 and SDL_gfx 3.0 (no dll for this last one, c files directly included). I currently can display images scaled and rotated (thanks to SDL_gfx), also calling SetAlpha will have an effect on displayed image. I still have a problem with rotation (as SDL_gfx always rotate according to the top left corner of the image, whereas Max2D can rotated according to whichever handle is set before) and alpha channel (which may produce garbage depending on images). I also receive keyboard and window close events and forward them succesfully to blitzmax internal event handler. If you want sources and try an example, go grab it at http://perso.wanadoo.fr/chrisgames/sdlmax.zip (windows only for the moment) (press ESC or close window to stop example). Is it worth creating a community project ? Waiting for your comments ... |
| ||
| what has happened to this project? |
| ||
| Personally I don't see the point of trying to fall back to software rendering, you're basically going back like 10 years in hardware progress. But I'm sure some people will disagree and so good luck with it. |
| ||
| i agree, any non-ancient PC has a graphics card, |
   |