Next Generation Emulation banner
1 - 18 of 18 Posts

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #1 ·
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 :D

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.
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #2 ·
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!
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #4 ·
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
 

·
Registered
Joined
·
30 Posts
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
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #6 ·
XTale said:
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
 

·
Registered
Joined
·
30 Posts
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).
 

·
Registered
Joined
·
30 Posts
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


 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #9 ·
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
 

·
Registered
Joined
·
30 Posts
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:
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #11 · (Edited)
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 :

Code:
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
 

·
Registered
Joined
·
30 Posts
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
Code:
Uint32 *mpLynxBuffer
by
Code:
Uint16 *mpLynxBuffer
.
Saving me 3 ANDs and 3 shifts per pixel --> faster :)
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #13 ·
XTale said:
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
 

·
Premium Member
Joined
·
129 Posts
Discussion Starter · #15 · (Edited)
XTale said:
edit: OK, got it
I replaced your
Code:
Uint32 *mpLynxBuffer
by
Code:
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) :D

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

XTale said:
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
 

·
Registered
Joined
·
30 Posts
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.
 
1 - 18 of 18 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top