Beta Improved Sdl


Has there been any work on this at all now? I know Notaz is busy with other things, but my BASIC interpreter really could do with accelerated SDL, at least for graphics (I've got a specially modified BASS library for sound, so I only need the graphics sections of SDL).

D.
 
sebt3 said:
notaz said:
Post the binary and I'll have a look
here
You are using old version of the lib, redownload http://notaz.gp2x.de/releases/pandora/omapsdl_latest.zip .

Dunny said:
Has there been any work on this at all now? I know Notaz is busy with other things, but my BASIC interpreter really could do with accelerated SDL, at least for graphics (I've got a specially modified BASS library for sound, so I only need the graphics sections of SDL).
What operations do you want to have accelerated, I assume blits?
 
Last edited by a moderator:
notaz said:
You are using old version of the lib, redownload http://notaz.gp2x.de/releases/pandora/omapsdl_latest.zip .
Oups, sorry. :(
But now, all I get is :

oshide: open /dev/tty: No such device or address
Segmentation fault
 
Last edited by a moderator:
notaz said:
sebt3 said:
notaz said:
Post the binary and I'll have a look
here
You are using old version of the lib, redownload http://notaz.gp2x.de/releases/pandora/omapsdl_latest.zip .

Dunny said:
Has there been any work on this at all now? I know Notaz is busy with other things, but my BASIC interpreter really could do with accelerated SDL, at least for graphics (I've got a specially modified BASS library for sound, so I only need the graphics sections of SDL).
What operations do you want to have accelerated, I assume blits?

Pretty much - I basically call a compositor at 50fps, which dumps the graphics generated by the language out to a SDL window's surface. Performance is not good on the Pandora, and is roughly 1/5th that of my 366mhz PC. Of course, it may be my code (or the FPC ARM cross-compiler) :)

I'd just like to see if it *is* SDL that's slowing me down so much, and if so what I can do about it.

D.
 
Last edited by a moderator:
I build a test-case for 800x600 downscalling, and it does indeed works.

I'll hunt my segfault then.
Sorry to have bothered you

EDIT : found : I was using -O3, setting it back to -O2 fixed it :huh:

EDIT2: The touchscreen event are *NOT* scalled
 
I ran a recent compile of PUAE (2.3.1) with this (hoping to run at a lo-res 320x256 and scale up using hardware, although not sure how much benefit this would give vs just running at the Amiga's native 640x480 (NTSC) hires mode.

Although I had PUAE configured to run in a 640x480, with the omapdss set it ran fullscreen, and also killed all input - keyboard/joypad become non-functional, although emulation continues. I have to hard reset as I can't kill the app. flipping back to the standard SDL and everything back to normal...
 
Thanks for this, fullscreen works really well and seems to run faster than the library included in the firmware.

Is it possible to overload the SDL_Flip function so the decision as to whether to wait for the vblank can be decided by the program rather than set at launch? Maybe SDL_Flip(screen,true) to wait or SDL_Flip(screen,false) not to, whereas SDL_Flip(screen) will use the default setting.
 
Thanks, that has worked perfectly. Time to upload my first PND! :)
 
Awesome! Correct me if I'm wrong but PyGame should be sick now, no?!?!?!?!?
 
EvilDragon said:
Have you enabled vsync?
That could lead to stuttering.

I get the same result enabling and disabling VSync.
 
Last edited by a moderator:
As it is Jagged alliance, why use hardwarescaling? Couldn't you just change it to render at Pandoraresolution?

Have a look at Local.h
 
mcobit said:
As it is Jagged alliance, why use hardwarescaling? Couldn't you just change it to render at Pandoraresolution?

Have a look at Local.h

Interesting idea.

Sure you get to see more of the tactical screen, but all the toolbars and world map weren't designed to render at 800 pixels width so you get ugly black spaces on the right hand side of the screen.
 
Last edited by a moderator:
Well, I'd say just try, maybe it will work.
When the tactical screens are not rendered at this resolution, well, then nothing is lost. To stretch these would look ugly too.
 
Yeah I gave it a try before typing the previous message. I guess it's a good compromise, the extra 25% tactical space makes up for the other cosmetic effects :)
 
Please don't kill me...

I've got a selfwritten SDL app here, I've putten the new lib into the directory and start it via this script:

#!/bin/sh
export LD_LIBRARY_PATH=./ // with and without
export SDL_VIDEODRIVER=omapdss
./myapp.pandora.bin

whithout the export lines it works, but with them SDL_Init(SDL_INIT_EVERYTHING) says "No available video device".


I think it's not a fault of the lib itself, but mine. Can you help me? I have no clue of this linux stuff....
 
Schnatterplatsch said:
Please don't kill me...
Oh yeah I will : double post... No kidding :p


Schnatterplatsch said:
whithout the export lines it works, but with them SDL_Init(SDL_INIT_EVERYTHING) says "No available video device".

Code:
   SDL_Init(SDL_INIT_VIDEO)
Then init these others subsystems you need to use.

later you need to :
Code:
SDL_SetVideoMode(x, y, 0, SDL_SWSURFACE);
 
Last edited by a moderator:
silver said:
I ran a recent compile of PUAE (2.3.1) with this (hoping to run at a lo-res 320x256 and scale up using hardware, although not sure how much benefit this would give vs just running at the Amiga's native 640x480 (NTSC) hires mode.

Although I had PUAE configured to run in a 640x480, with the omapdss set it ran fullscreen, and also killed all input - keyboard/joypad become non-functional, although emulation continues. I have to hard reset as I can't kill the app. flipping back to the standard SDL and everything back to normal...
Except that Amiga hi-res NTSC is 640 x 400 not 640 x 480 (low res is 320 x 200).
 
Last edited by a moderator:
Back
Top