FAQ

Things to have in mind when developing with the Gamepark SDK.

Last update: 2005-04-14

 

Here you have a little FAQ to help you in not doing the same errors as me when developing with the Gamepark SDK.
Of course it's incomplete, and also possibly not 100% correct. So, if you think that a question should be in there, or there is an error, don't hesitate and drop me a mail.

1. Graphics

2. SMC

3. Gamepark SDK: bugs & unexpected behaviour

4. Compilers

 

1. Graphics

1.

 Q: I'm trying to access the screen writing directly to the memory, but when I put a pixel at the first address, it doesn't appear at the top-left corner but instead it appears at the left-bottom corner. Why?  

 

 A: GP32 screen is originally a PDA screen. That means that internally it's a vertical screen. What has made Gamepark is simply to rotate the screen 90 degrees counter clockwise. So, if we extrapolate we find that the hardware X goes from top to bottom and the hardware Y goes from left to right. That explains also the fact why Gamepark SDK graphic functions expect rotated bitmaps.
Keep this system coordinates in mind if you want to make fast screen routines.

2.

 Q: I have a 50x50 bitmap embedded in my program, but when I use GpBitBlit(), the GP32 shows garbage. What happens?  

 

 A: If you use 8 bit graphics, bitmap width and height must be multiples of 4. If you use 16 bit graphics, bitmap width and height must be multiples of 8. If you don't follow this rule, you will have unpredictable results.

3.

 Q: I'm drawing a square with GpRectDraw16() using color 0xFFFF with the SDK for Windows. Why do I get a blue square and not a white one?  

 

 A: See question 3.3.

 

2. SMC

1.

 Q: I'm trying to open a file that is located on the SMC, but the function is always returning me and error. What can it be?  

 

 A: Before any access to the SMC, you must execute GpFatInit() that will initialize the SMC system.

 

3. Gamepark SDK: bugs & unexpected behaviour

1. Q: I have compiled my program using the Gamepark SDK for Windows. But when I execute the executable file, I always get an error just when I choose a Virtual SMC file that basically tells me that the memory can't be written. The program runs correctly when I compile it for ARM and use Geepee32. Where is the problem?  

 

 A: I don't know why, but in some computers, you get this type of error if you execute the .exe file when your screen is configured in 16 bits colors. Change the configuration to 24 bits colors, and see if the problem is solved. Usually, in this computers you will also have the same problem with Geepee32 that runs correctly only when the screen is configured in 16 bits colors.

2.

 Q: I'm using a Gamepark SDK function that works when I compile for ARM (e.g. with devkitARM), but doesn't work when I compile for Windows with VC++ 6. This SDK seems buggy, what can I do?  

 

 A: Soon.

3.

 Q: I'm drawing a square with GpRectDraw16() using color 0xFFFF with the SDK for Windows. Why do I get a blue square and not a white one?

 

 A: It's a bug of the Gamepark SDK for Windows. You have two solutions:
1: do nothing, it's not so important since the same function compiled with the ARM libraries works correctly.
2: prepare a patched version of the function as explained in 3.2. 

 

4. Compilers

1.

 Q: Structure problems.  

 

 A: Soon.

2.

 Q: Inline declaration of variables problems.  

 

 A: Soon.

 

 

6. How to patch an SDK function that doesn't work as they should.

Some functions in the Windows libraries doesn't work correctly. A way to keep going is redefining the function. In the compatibility.c file located in the main Include folder you will find some functions of the SDK redefined by me, and even the functions of CHN's libmodplay library (these are only empty functions to be able to compile).

You can add any function you may need.

Here I will explain how to redefine the GpAppExit() function (it's already done).

Create a new folder into your projects main folder.

Copy all files in 16bitsTest folder into the new folder.

Optional: rename the .dsp and .dsw files to the new project name.

Optional: open the .dsp and .dsw files with an editor like Notepad and replace all occurrences of the string 16b_test with the name of the project.

Optional: if you have a makefile, do the same with it.

 

 

  Unfortunately some functions of the SDK doesn't work correctly, but don't worry as I will also include a way to patch the faulty functions you will find while you code.

You shouldn't spend more than 10 minutes to setup the SDK and test it.

Note: The project file included in the test file is not optimal. It would be a lot more useful if it contained a third group of settings to compile directly for the GP32 with, for example, devkitARM, and launch the executable with Geepee32.
I've tried, but didn't manage to do it. If someone finds the solution, please send it to me and I will include it in the test program.