[nwagenaar]

Hi everyone,

A long time no see! Because of courses (MCSE) and work, I wasn't able to get anything done lately. And atop of it all, it's hard to code on a machine which is broken. Luckily I got to fix my devstation since last weekend and since last night I've been working on Handy/SDL.

Ok. First things first. The 'old' Handy/SDL is gone. It has fanished in thin air and I even tried to recover the code from three old harddisks using testdisk (nice programm BTW). I did get old BoyCott Advance/SDL and NeoPocott/SDL code back but that was it. So I need to rewrite the code and begin from the beginning.

I'm now 24 hours away and I got Handy running on SDL (WIN32). It has graphics (normal SDL rendering), keyevent support and throttle code in place (mainly since the compiled binary ran like 1000+ FPS and was hard to test). Now to implent some scaling routines, OpenGL rendering en configfile support. Sound- and netsupport are low priorities atm. After this is done, a first (source) release will be made. Hopefully this Christmas as a gift

Since I got a GP32, I want to try this source on GP32-SDL and to get it running on a GP32

Anyway,

I'll keep you posted on the progress.

 

[nwagenaar]

Just to let you all know. The source of Handy/SDL v0.1 is now available from here.

Development was done on a WIN32 system running the latest mingw (stable) release, SDL v1.2.9 and Zlib 1.1.3. Compiling is straight forward (hint : make) and it should compile on most platforms/systems without problems.

This version has primary sound, primary graphics and primary handling. It still needs a lot of work but the basis is here. The source is quite clean and should be readable enough for most If you have problems, please post them in this forum. Sollutions, patches are also welcome!

 

[XTale]

I ported it for the GP2x:

Problem: Slow like hell (maybe 1-2FPS)

 

[nwagenaar]

Wow! That's really cool! I haven't recieved my GP2x yet, but I have an explenation why it's so slow. The entire rendering (Handy core and SDL video output) is done on 32bpp and this could be the problem.

As I write this, I'm updating the sources for support of multiple bpp rendering types. This will possibly speedup the speed of Handy/SDL. Also, it's a straight forward port and it doesn't have any speedups or hacks at all.

BTW, did you need to change anything to get it working (maybe only a Makefile hack). If so, please e-mail me the changes to shalafi AT xs4all DOT nl

Regards,

Niels Wagenaar
SDLEmu

 

[XTale]

Mostly Makefile-Hack.
I'd to change some parameters in handy_sdl_graphics, as the GP2x only supports 320x240 and no doublebuffering.

There is also a SegFault if the lynxboot doesn't pass the check (rom.cpp somewhere round 113), gError doesn't seem to be initialized.

ATM my code is very ugly, so I better don't mail anything yet
I try to modify the graphics_output to write directly to the gp2x framebuffer - should be a lot faster than using sdl-rects

 

[nwagenaar]

Mostly Makefile-Hack.
I'd to change some parameters in handy_sdl_graphics, as the GP2x only supports 320x240 and no doublebuffering.

There is also a SegFault if the lynxboot doesn't pass the check (rom.cpp somewhere round 113), gError doesn't seem to be initialized.

ATM my code is very ugly, so I better don't mail anything yet
I try to modify the graphics_output to write directly to the gp2x framebuffer - should be a lot faster than using sdl-rects

Please do e-mail your changes, even if it's ugly code. I can streamline this and incorperate these using ifdef's (for instance SDL_GP2X or something).

I would really appreciate it!

Regards,

Niels Wagenaar
SDLemu

 

[XTale]

I will port it to direct framebuffer access first.
I have it partially running - and it seems to be full speed, but the picture is still ****ed up (doing something wrong during writing into the buffer).

 

[XTale]

ok - got it ported, and it seems to run nearly with full speed (not sure though...)

GP2x owner should give it a try and feedback

I sent the sources to nwagenaar and he will most likely merge them inside the handysdl code.

You can get the binary download here

 

[nwagenaar]

The news about the GP2X WIP port is now put on the frontpage Also for people who want to take a risk, I've uploaded the first Handy/SDL v0.2-WIP sourcecode [LINK].

Added :

- Selection/Autodetec for setting the bpp;

This way you can choose the bpp on which it should render. As a plus, it also gave a speed increase (roughly 50% more speed) and it's now a better foundation for adding new graphics options. Furthermore, it now has a solid foundation for future graphical extensions as scaling and such

As soon as new updates are available, I'll post them on the frontpage and here

Regards,

Niels Wagenaar
SDLemu

 

[XTale]

hm - your autosetting of the bpp broke my gp2x port...
you're sure that we have rgb565 values inside the mpLynxBuffer now?
Because directly copying them to the framebuffer results in a doubled picture:

 

[nwagenaar]

I'm very sure! I tested it on nVidia as wel on ATI hardware and it both produced the same results. If it was the RGB565 values, you would have had colour problems and not twice the video-output.

However, I don't know if you use the SDL backend or the GP2X framebuffer. But it looks like if the DisplaySurface mainSurface or your created primary display is twice as wide. You might try changing the memcpy in the handy_sdl_render_buffer(void) function (handy_sdl_graphics.cpp) to the following :

memcpy(HandyBuffer->pixels, mpLynxBuffer, LynxWidth * LynxHeight* 2); // Was bpp. Should be two for 16bpp. 
or
memcpy(HandyBuffer->pixels, mpLynxBuffer, LynxWidth * LynxHeight); // Was bpp.

Perhaps you could tell me which bpp you use? You could try setting the bpp to 15, 16, 24 or 32 and see if it produces the same results.

Regards,

Niels Wagenaar
SDLemu

 

[XTale]

ok.. i see the problem
I'm directly writing to a 320x240 framebuffer with 160x100 inputdata... it's clear that it produces an output like this...


edit: OK, got it
I replaced your

Uint32 *mpLynxBuffer

by

Uint16 *mpLynxBuffer

.
Saving me 3 ANDs and 3 shifts per pixel --> faster

 

[nwagenaar]

ok.. i see the problem
I'm directly writing to a 320x240 framebuffer with 160x100 inputdata... it's clear that it produces an output like this...

Correct! :thumb:

And that's the why I use the mpLynxBuffer, SDL_Display *HandyBuffer and SDL_Display *mainSurface. Because I copy the contents of the mpLynxBuffer to HandyBuffer (which has the exact same dimensions as a Lynx LCD screen) I don't have this problem.

In the new code ( not yet released(tm) ) I can make mainSurface any size I want and use the mainSurface for displaying scaled images, OpenGL rendering, filters, etc. I just manipulate the pixel data from HandyBuffer and display it on the mainSurface in every way I want, without needing to worry about HandyBuffer (size, pixel data or otherwise).

Regards,

Niels Wagenaar
SDLemu

 

[XTale]

you should join irc

 

[nwagenaar]

edit: OK, got it
I replaced your

Uint32 *mpLynxBuffer

by

Uint16 *mpLynxBuffer

.
Saving me 3 ANDs and 3 shifts per pixel --> faster

Ok, now you've set the support for rendering in only 16bpp. Now you can work on the scaling code (which you got working for 0.1a I saw)

BTW, did you allready try the "original" SDL source (instead the use of the GP2X framebuffer) and tell me if the speed had increased?

you should join irc

Wish I could. I'm currently at work and policy states : no IRC/MSN/ICQ/etc allowed on workstations. And the funny thing is, I made that policy. Otherwise I would keep devving also on my work

Regards,

Niels Wagenaar
SDLemu

 

[XTale]

As the gp2x just supports 16bit rendering "limiting" it to 16bit is no problem at all.

No, I didn't yet try your SDL rendering on the gp2x (too lazy to undo all my changes again )

 

[XTale]

Although your SDL port made me start to port it to the gp2x, my new version (0.2) makes no more use of SDL at all
I removed all the SDL stuff and replaced it by a minimal library which encapsulates the direct gp2x hardwareaccess to speed up the emulation.

 

[XTale]

For those who want to test the 0.2 WIP source but can't compile it:
I put a compiled (windows) binary at http://cvscompile.aep-emu.de/specials.htm


edit: yeah - tripplepost