Some Sdl Help For Pandoros

[craigix]

I've been trying to get the pandora OS ported over to windows in a 800*480 window so you guys can try it early and we can all tweak it up.

However windows programming drives me mad 'test.exe must close' etc. great.

Here is there problem in a nutshell:

I don't use SDL for the OS, it is just direct to hardware, however in windows I understand the best way to get a framebuffer is via SDL.

So I've got SDL working with visualC and got my 800*480 screen open.

Now I've also managed to get my OS code (with some ugly hacks) compiling in windows.

And as far as I know it is running.

Now here is the issue, I cannot seem to figure out how to copy directly on to that SDL buffer without getting the 'This program must close' crap.

So here is some code, what on earth do I need to put where the ****** part is to access the SDL buffer? I've tried all sorts of hacks and can't seem to get anything to work, usually just crashing windows.

Sorry if this seems very newbie but I'm not used to SDL or windows, and I don't know how SDL sets up its screen buffer.

I do understand that a 32 bit frame in windows should be 8:8:8:nothing.

void sdlHACK(SDL_Surface *surface) // forces the non sdl famebuffer on to the SDL frame
{

int height=480;
int width=800;
int xl=0;
int yl=0;
int n;
int nt;
for(n = 0; n < height; n++){
for(nt = 0; nt < width; nt++){
****** = pandorascreen[((n+yl)*SCREENWIDTH)+nt+xl];
}
}

}

 

[mindlord]

You have to lock the SDL surface for direct writing with SDL_LockSurface, and lock it back before flipping it.

 

[Alex.]

Try this:

CODE

void sdlHACK(SDL_Surface *surface) // forces the non sdl famebuffer on to the SDL frame
{

int height=480;
int width=800;
int xl=0;
int yl=0;
int n;
int nt;

if(SDL_MUSTLOCK(surface)) SDL_LockSurface(surface);

for(n = 0; n < height; n++){
for(nt = 0; nt < width; nt++){
*(Uint32*)(surface->pixels + n * surface->pitch + nt * surface->format->BytesPerPixel) = pandorascreen[((n+yl)*SCREENWIDTH)+nt+xl];
}
}

if(SDL_MUSTLOCK(surface)) SDL_UnlockSurface(surface);

}

 

[craigix]

I get:

.\test.cpp(258) : error C2036: 'void *' : unknown size

on: *(Uint32*)(surface->pixels + n * surface->pitch + nt * surface->format->BytesPerPixel) = pandorascreen[((n+yl)*SCREENWIDTH)+nt+xl];

 

[Alex.]

Oh, then try

*(Uint32*)((Uint8*)surface->pixels + n * surface->pitch + nt * surface->format->BytesPerPixel)

 

[craigix]

That does compile but instantly crashes with the 'app must close' error, but I'll keep playing around with it, if that code is correct I've got a few ideas of how to test it.

If it won't work I'll compile a version for the GP2X in which you can zoom in and out to create a virtual 800*480.

 

[pepone]

That does compile but instantly crashes with the 'app must close' error, but I'll keep playing around with it, if that code is correct I've got a few ideas of how to test it.

If it won't work I'll compile a version for the GP2X in which you can zoom in and out to create a virtual 800*480.

What is the format of pandorascreen? 16 or 32 bpp?
Also, how do you create your SDL surface?
Does it crash even if you copy only one line of pixel?

Here is how I would do it:

SDL_Surface *p_screen,*real_screen;
char *pandorascreen;
real_screen= SDL_SetVideoMode(800, 480, 32, SDL_SWSURFACE|SDL_DOUBLEBUF);
p_screen=SDL_CreateRGBSurface(SDL_SWSURFACE, 800, 480, 32, 0, 0, 0, 0);
pandorascreen=p_screen->pixels;

Then, you can write wathever you want in pandorascreen (you may need to lock the surface before), and then blit it on the real screen:
SDL_BlitSurface(p_screen, NULL, real_screen, NULL);
SDL_Flip(real_screen);

 

[Pickle]

I've been trying to get the pandora OS ported over to windows in a 800*480 window so you guys can try it early and we can all tweak it up.

The perating system is linux, so Im a little confused what you mean by OS?
Are you just talking about the laucher applcation (i.e. Gmenu2x)?

 

[craigix]

I'm just calling the GUI PandorOS for now, I'll probably rename it something else later.

The idea of this port is that it sits on top of windows not linux so people on here can try it out.

 

[Pickle]

I'm just calling the GUI PandorOS for now, I'll probably rename it something else later.

The idea of this port is that it sits on top of windows not linux so people on here can try it out.

ok, thats what i thought.
If you use the CB dev kit and mingw, you could use gdb and debug through the code to determine where your crash is occuring.

 

[habib15]

Why not just distribute a Linux version? Most people can boot a Live CD to test it out if they're not running Linux natively.

 

[Pickle]

Why not just distribute a Linux version? Most people can boot a Live CD to test it out if they're not running Linux natively.


Edit: never mind, i misread and thought you expected to boot the application.

Can you access the framebuffer on different linux distro's is the address standard? Isnt it possible the Pandora's frame buffer is in a different memory location than a x86 linux?

 

[habib15]

Can you access the framebuffer on different linux distro's is the address standard? Isnt it possible the Pandora's frame buffer is in a different memory location than a x86 linux?

I think it depends on how he is writing the GUI. If he's using GTK+ then the application would run on any distro with those libraries and the windows manager would take care of writing to the frame buffer/X server.

I'm not sure if thats correct I haven't started doing any embedded linux GUI's yet, but would like to very soon. I've worked more with low level drivers and board support packages.

 

[craigix]

Thanks for the help everyone, I've decided to just release a version for the GP2X as Windows is wasting my time

 

[Arialia]

Thanks for the help everyone, I've decided to just release a version for the GP2X as Windows is wasting my time

I made for you a little sample ( i'm also a beginner in SDL this evening )

in my example writing directly in the framebuffer is made by fonction setpixel() (thanks to tuto of siteduzero )

Use CodeBlocks make easier dev


GUIPandoraW.zip

 

[icurafu]

Arialia, is this the offical one? Anyway, I'll look as soon as I get the SDL ddl.

 

[Chip]

Arialia, is this the offical one? Anyway, I'll look as soon as I get the SDL ddl.

Nah, it's just an example of how to get a FB program to display in windows with SDL.

I guess I'll have to wait for a GP32 port - I never upgraded to the 2X

 

[yosh64]

hey

I'll beable to quickly wip something together for windows if ya like.

Well ya can probably use my SDL framework class (haven't tested it on linux yet, but should work), but if ya like I can just paste each of my functions so ya can just use/do what ya want. Anyhows in my lib I draw directly to the framebuffer, and you can draw at whatever scale .

BTW, I don't think ya have to bother to lock/unlock the screen when on windows, but I'm not 100% sure on this (I might quickly check).

Otherwise if ya determined todo it yaself then ya might wanna checkout the first few parts of Sol's Graphics tutorials.

Hmm, if ya want just email me the source (don't have to send assets, although I wouldn't know if it worked for sure) and I can probably try port it tonight.

BTW, I use mingw32/g++ and not visual c++, so I dunno if my code would compile for ya.

Also, are there any GP2X emus that we could use to check it out if ya not gonna bother with windows/linux? and what about screenshots?

Anyhows this is kinda exciting, hehe.

edit
Yea, just tested on winxp and on my computer ya don't need to lock/unlock the screen. Although it's best to use these functions just in case , well I still use them in my code anyhows (well it only locks/unlocks if needed).

another edit
Craig, if ya interested in my offer, or ya want to look at or try the source of some of my functions then just email me and I'll send to ya.

and another
Ahh, I see Arialia has posted some code already, well alot different to mine (Although I only support RGB pixel format, but I use 32bit surface, and I draw a whole sprite at a time rather than a pixel. But yea, guess that's just to show ya to draw a pixel to the framebuffer ). Anyhows shouldn't you lock the screen before ya call SDL_FillRect() to clear it or must ya only lock the screen when directly accessing the framebuffer?

cyas

 

[quasist]

for(n = 0; n < height; n++){
for(nt = 0; nt < width; nt++){

SDL_LockSurface(screen);
memcpy(screen->pixels,scrbuf,SCRBUF_SIZE); //strings.h
SDL_UnlockSurface(screen);

is much faster solution
Bloating thine code already?

as Windows is wasting my time

you are the one wasting the Windows' time

 

[Tinnus]

I'm also available to do Windows SDL hacking. I've even managed to init a window with SDL in Windows and making OpenGL ES 2 (ImgTec emu DLLs) render to it