protrekkr being slow has nothing to do with sdl. the realtime synth is cpu hungry.
Swithed off ,on protrekker, and no improvements (allways slow) when playing the song.
This suggestion is more for maybe a new release of this program (with the new AOS4.1U1 recently). Maybe protrekker will run with more speed now.... ????
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
I'd just like to point out that ANYONE can work on OS4 SDL, you don't need permission, you can check out the SVN code at any time and work on it.
People often ask me to fix SDL, but if its GL related, i really don't know how to fix the problems (i've tried a couple of times). Also, my life these last few months has been a LOT busier than I expected. The only time I have for hobby programming is on the train (on my laptop) which is why there has been a lot of progress on Oricutron (I can code/test on Windows, and compile it on Amiga later), and not much on Amiga-specific projects (like the OS4-specific parts of SDL).
Anyway, if someone makes some fixes and wants commit access, they just have to ask me or Hans-Joerg.
If you are a developer and want to help improve OS4, SDL is one place where you can make a big difference right now.
There are some things that REALLY need to be done and are probably easier than fixing the GL issues:
* Prepare a new release of the current code. Apparently, I cocked some things up with my releases (statically compiled GL into the shared object, included an out-of-date static libSDL.a in the newlib archive...)
* Fix the bugs that Spot keeps nagging me to fix E-mail him for more info. Some of them are probably even quite easy to someone with the time to do it.
* Bring the code in line with 1.2.14. This is probably easier than it sounds. To go from 1.2.11 to 1.2.13, I downloaded the 1.2.11 OS4 sources to my PC, and used Beyond Compare to compare them to the official 1.2.13. I merged in all the changes, tweaked the configure script a bit (there were some new parts for 1.2.13 that required an amiga section), copied the result to the amigaone, configured it and built it. That was it, aside from some tweaking.
When you configure SDL on the amiga, just remember to disable pthreads, and it'll then use the OS4 native threading (for some reason it picks pthreads by default).
* Prepare a new release of the current code. Apparently, I cocked some things up with my releases (statically compiled GL into the shared object, included an out-of-date static libSDL.a in the newlib archive...)
well, i've a libSDL.so that works correctly and that load MiniGL without problem. I've only reconfigured and compiled the trunk.. so you should do the same without problem and without have to link nothing statically
BTW, i'll try to use SDL in Window mode but there is a problem that avoid vid_AllocDepthStencil in the MiniGL function that call IWarp3D->W3D_AllocZBuffer to works correctly. I've print the most important field like width, height and so on and all seems ok. I receive a W3D_NOGFXMEM from warp3d but i don't know why.. the videomemory is almost free (52MB) and i don't think there is no memory for a 320x256x16 buffer.. Since i don't have no clue why Warp3D fail i give up for now
for sure It's 68k but surely problems are on all versions. I haven't the knowledge but surely on utilitybase some help coould be found...
Additionnaly, you could post about his problem on utilitybase and surely alain thellier (wazp3D author) will surely answer. I think he know verry well the problems of Warp3D.
Yes, I also would like to see a great warp3D/SDL and miniGL working on AOS4
A1200+Mediator+VooDoo3+060/50+96mo+IIYAMA 17"+CD,CDRW,ZIP SCSI-KIT SAM440EP on Mapower 3000+AOS4.1
afxgroup wrote: BTW, i'll try to use SDL in Window mode but there is a problem that avoid vid_AllocDepthStencil in the MiniGL function that call IWarp3D->W3D_AllocZBuffer to works correctly. I've print the most important field like width, height and so on and all seems ok. I receive a W3D_NOGFXMEM from warp3d but i don't know why.. the videomemory is almost free (52MB) and i don't think there is no memory for a 320x256x16 buffer.. Since i don't have no clue why Warp3D fail i give up for now
I don't quite understand this. GLUT has no trouble with windowed mode, and neither does Blender, which does its own buffer management.
How are you creating the MiniGL context? What are you doing to set the front and back buffers? If you need help with this, talk to Andy (Broadblues) about how he did the buffer management in Blender.
maybe there is something different between two modes and something is not initialized correctly when SDL fill the context values but since i don't know why AllocZBuffer fail (except for that error code) it is hard to know what is wrong
If I understand correctly, windowed mode is not implemented for SDL with GL yet.
Glut uses the internal minigl windowed mode, whereas blender uses a custom mode using the new tags with give greater control over the buffers, I suspect SDL will need to take the 'blender approach'.
As well as lacking windowed mode there doesn't seem to be any support for GL double buffereing either, I can take a look at this eventually but at the meoment my time is full for a few weeks at least, so if anyone else wants to have ago, I'll happily answer questions on the tecnique I used for blender, and the meanings of the new minigl context creation tags.