Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Considering GP2X version Crashblock

  1. #1

    Considering GP2X version Crashblock

    I believe there are a few people on here who have knowledge in this area

    I want to make a build of Crashblock which runs on a GP2X.
    If it's viable option and what needs to be done to the game to get it to work.

    Crashblock is written using Pascal, it compiles using FreePascal for both Linux and MacOSX. It uses SDL for all graphics, SDL_Mixer for all sound. it is not hardware accelerated.

    My questions are:

    1, Crashblock runs at 800x600. All of the graphics are fixed for this resolution. Will I have to make any changes to the rendering engine? I am aware that the GP2X has a resolution of 320x240, will it scale it down for me or am I looking at building a completely different version and re-sampling all of my graphics to make it fit? (Thinking about this, a GP2X version may do better with a scaled down version due to it's limited horsepower)

    2, The GP2X has a dual core, does this take care of load balancing it's self or is it a threading thing which needs special coding to get the most out of? I'm hoping that the machine can use its processors intelligently so I don't have to alter my game too much.

    3, How easy is it to develop for?

    If I can get it working, I see a fairly large potential market, given that it can also display on a TV, this seems to be a cheap way to break into the Non-PC game market.

    Any advice would be a huge benefit for me.

  2. #2

    Considering GP2X version Crashblock

    I don't know about the GP2X, but I'm pretty sure you'd need to fiddle with the screen size and layout for the console.

    I would imaging crashblock would be nice on the NDS as well, SDL works on that, and you have 2 screens to play with, but the assets would probably need some work I guess. Then there is the problem of deployment...
    <A HREF="">
    <br /><IMG SRC="" BORDER="0">
    <br /></A>

  3. #3

    Considering GP2X version Crashblock

    Well, I have a GP2X at the moment, my Boss has one and he's letting me use if for a few weeks so I can try it out.

    I'm not overly worried about resizing the graphics to make it work on a smaller resolution. I'll just have to write something to automatically resize the assets.

    Then I'll have to put some kind of scaling factor on everything, I already have code for this built into the engine.

    If the NDS uses a similar resolution to the GP2X, then it might be possible to port it to that too. But, I don't know how people would be able to install and play it.. I know that I can ship something legally for the GP2X.

    I'm also quite excited about the new version of the GP2X, it has a touch sensitive screen, my new menu options are big and chunky which would suit a touch screen perfectly.

  4. #4
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Blog Entries

    Considering GP2X version Crashblock

    If you wanted to do a GBA/NDS port, you'd be looking at making a single ROM file for use in an emulator. Using SDL means that you'd be using a version it that would compile right into your ROM file. Legolas knows a lot more about this.

    As for distribution, I know that if you are giving it out as freeware you're more than ok to do that. Selling it is something of a gray area though. I recommend reading up on how this is done by other companies that don't want to pay for Nintendo licenses. As mentioned in another thread, Nintendo has a checkered pattern of suing gaming companies that have sold such games. I'm unfortunately not up-to-date on the hardware aspect of this as GBA/NDS games to be sold in a more traditional/practical fashion would require physical packaging. (Shipping to customers would be relatively cheap however! )

    As for the GP2X, it's more like making a Linux port, but with a smaller screen and fixes set of controls. Paul Nicholls would be best able to answer this question for you.

    I do know that SDL thrives on this handhelf system. And the alternative to this is most likely OpenGL|ES.

    I think your first challenge with GP2X is figuring out if all the essentials are ready for use;

    :arrow: Reading controls
    :arrow: sound
    :arrow: file system
    :arrow: graphics(but I'm sure this is easiest)
    :arrow: packing of game into format that the GP2X will be able to load and run.
    Jason McMillen
    Pascal Game Development

  5. #5

    Considering GP2X version Crashblock

    Does Jedi-SDL compile on GP2X out of the box?

    I've not compiled anything on Gp2X yet, not even as an experiment, I've been so very busy. It'll be a massive stumbling block if it doesn't compile.

    Are there any examples of Jedi-SDL games which have been ported to GP2X I can take a look at?..

  6. #6

    Considering GP2X version Crashblock

    Hi Jason :-)

    It is really cool that you are thinking of trying to port your game to the GP2X!


    I know that the console can do rescaling if it is set up correctly, but I can't recall if it is when playing movies for example scaled to the GP2X screen, or when doing TV out.

    The hardware registers need to be fiddled with to do this sort of thing I believe.

    I have just made my own scaled down graphics to fit the 320x240 mode that get used instead of the NxM resolution used on the PC.

    I have some ARM assembly code that I compile into my GP2X programs to allow direct hardware access to the console, but I haven't done anything with this except directly write to the framebuffers instead of using SDL for the output as some tests.

    Without using direct hardware control and possibly ARM assembly code as well, the second ARM processor is not used for normal programs.

    So there is no automatic load balancing there. I don't know about threads, but I suspect that the same applies there; all on the main ARM processor unless programmed otherwise.

    I can use pure JEDI-SDL code to do graphics on the GP2X no worries :-)
    I have noticed when trying freepascal 2.0.4 and 2.2.0, using the SDL_Mixer crashes the console for some unknown reason - you may have seen some posts floating around about this.

    I can do sounds using .wav files using the standard SDL sound stuff but not with the mixer yet

    With freepascal 2.0.4 I had trouble loading PNG images as well...I haven't tried under 2.2.0 yet to see if that is improved. I can load BMP files with no issues though...

    I hope this helps a bit.


  7. #7

    Considering GP2X version Crashblock

    Hi Paul,

    yes, your post helps a lot.
    I've seen that you've been working with the GP2X and was kinda hoping that you'd have some advice for me.

    Crashblock uses SDLMixer for all of it's sound, so any movement on this mixer issue would be important for me.
    All of the sound effects are OGG Vorbis. I've noticed that ogg playback can be a little choppy.. is this something you've found too?

    I use PNG's for a lot of the graphics, at the moment only so my transparent colour doesn't get smudged in the compression (as would happen with a jpg)
    But with the lower resolution, I was considering using the PNG Alpha channel to improve the image quality.

    Perhaps there are some updates to SDL for pngs and ogg vorbis?

    Most of the grunt work done in Crashblock is image rendering, I'm hoping that a 40% decrease in image size will help with many performance aspects.. including collision detection. But I'm not sure if it'll be enough.. I guess only by testing will I find out.

    Also, Crashblock runs in 16bit colour. Would reducing this further to 8bit make things run faster? What are you using?.. if the GP2X's resolution is 16bit (not sure) then translating between 8 and 16 will use eat processor cycles.

    have you noticed any performance differences between using pure SDL and your direct framebuffer code? If so, is it an extreme difference? I would have thought that SDL would do a reasonable job of accessing the frame buffer.

    It's a very cool console and I really want to get Crashblock working on it.

  8. #8

    Considering GP2X version Crashblock

    Hi jason,

    I am thinking of trying one idea with regards to the SDL_Mixer...I will attempt to make build a C *.o file using the devkitGP2X that will allow me to access the SDL_Mixer stuff via freepascal to see if that fixes the crashing issue.

    I haven't tried playing ogg vorbis files on the GP2X, but I know it works when programming it using C/C++.

    I do need to test to see if PNGs work under my current GP2X compiling system.

    I generally use 16 bit depth with SDL as standard so it works directly on the GP2X without it having to convert between another color depth and 16 bit.

    When writing to the framebuffer directly you have to write ALL the drawing code yourself - lines, rectangles, etc.

    I haven't done enough tests to see if the direct framebuffer code is faster than using SDL, but if the drawing code is "efficient", then I suspect it is as quite a few people programming the GP2X do use the framebuffer method in order to get speedups for things like emulators, etc.

    If you happen to be using OpenGL at all with Crashblock, then you will have to completely write your own fixed-point math OpenGL emulation code (to be fast) as the GP2X doesn't have OpenGL at all (or even a 3d processor).

    I did make my own Pascal primitive OpenGL code that used the basic OpenGL calls but it was really slow as I hadn't done much optimization for the GP2X.

    PS. Long live the GP2X!!
    PPS. I also love the sound of the upcoming new model with touch-screen and "D-Pad"


  9. #9

    Considering GP2X version Crashblock

    I'm really excited about the touch screen too, it's perfect for Crashblock's new menu system. As long as it behaves like a mouse and SDL receives a mouse move event followed by a mouse click event, then I won't have to change any code at all..

    I managed to get your example code to compile and run on the GP2X last night (no skill required to run a batch file after setting up the environment eh? )

    I noticed that your example project contains your modified SDL files, are these changes to the JEDI headers going to be incorporated into the current JEDI?

    I noticed also that all of the controls are buttons.. does this mean that the GP2X joystick is just 4 buttons or is this just how things have been implemented? I mean, I don't really care either way, I treat joystick directions as digital events at the moment, but if I wanted to make a game where how hard or how far you press the joystick influences turning speed or something like that, is that possible in your knowledge/opinion?

    I'm not using OpenGL, I've kept everything using native SDL calls though the JEDI-SDL headers. I feel this offers the highest compatibility and future proofing..

    Is the problem with SDL_Mixer an issue with FreePascal or the C-compiled file? (does the GP2X use .so files?)

    I'm all questions aren't I? :lol: but it's all for a good cause, the more I can understand about this and the things which need to be done, the faster I can get something working on it.

    I'm not a big fan of fettling though, I like to just compile stuff and it works so any advances which can be made on the mixer/png/ogg front would be brilliant.

    Then, we'll have another commercial game for the GP2X

    Here's a taster (faked of course)

  10. #10

    Considering GP2X version Crashblock

    Well, I did do some experimentation on the GP2X, I modified your test application to play an Ogg file (unsuccessfully ) On initialisation of the audio system, it crashed. Reading on the dev forums, there's some other version of SDL, I'm not sure if this is to be shipped with the game or statically linked in.. but it claims decent hardware performance and ogg vorbis support.

    But it started to get all technerdish and I glazed over. I just want to write a game that anyone can play without them having to install anything else. Perhaps I misunderstood the requirements, but then again, the documentation was not wonderful.

    I was going to try some other things but I've run out of batteries :lol: and I'm getting the dreaded flashing rainbow of death

    I would really love to see something someone has got going on the GP2X in Pascal, something meaty which I can compare so I know how much power I've got to work with.. The CPU is something like 230mhz but it's a RISC processor so it should be run things at a similar speed to a 350mhz intel or higher if coded properly.

    I'm also a little worried by the size of the executables being generated for the GP2X, just your test app is over a meg. Crashblock is only 700k for the entire game. Please tell me there's a way to reduce the file size.

Page 1 of 2 12 LastLast


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Comodo SSL