| Should I begin compiling notes about functions and add them as doxygen comments in the Prizm SDK header, allowing function documentation to be available? |
| Yes |
|
88% |
[ 8 ] |
| No |
|
11% |
[ 1 ] |
|
| Total Votes : 9 |
|
(This topic is being slightly hijacked)
Since most of the documentation is not written and is found by example in other prizm topics or programs, I am going to compile documentation from this thread and create a doxygen page. Vote in the poll on your opinion and post in the thread with your comments/usage/quirks/notes about functions!
(original post)
As there is a lack of notes in the SDK, I am lost.
Here's a start: PrintXY - How would this be used at all on the prizm?
Basically, there needs to be documentation, not examples posted.
Second, nothing with the Prizm SDK for me compiles. I get this
Code: [Joshua@Joshua test1]$ make
/usr/local/cross/bin/sh3eb-elf-g++ main.o -mb -m4a-nofpu -mhitachi -nostdlib -T/home/Joshua/Download/PrizmSDK-0.3/common/prizm.ld -Wl,-static -Wl,-gc-sections -L/home/Joshua/Download/PrizmSDK-0.3/lib -lfxcg -lgcc -o /home/Joshua/Download/PrizmSDK-0.3/projects/test1/test1.bin
main.o: In function `_main':
main.cpp:(.text.startup+0x2c): undefined reference to `Bdisp_AllClr_VRAM()'
main.cpp:(.text.startup+0x34): undefined reference to `PrintXY(int, int, char*, int, int)'
main.cpp:(.text.startup+0x38): undefined reference to `GetKey(int*)'
collect2: ld returned 1 exit status
make[1]: *** [/home/Joshua/Download/PrizmSDK-0.3/projects/test1/test1.bin] Error 1
make: *** [build] Error 2
Nothing special, in projects/test1/. This is using a cpp file with g++. There shouldn't be a linking error, but there is.
<edit>
I need extern "C" in the cpp file, right? 
I don't know how to get it to work under Linux, so I can't really help you there. As for the PrintXY, look at Minesweeper to see how it would be used. You use it to print a string to and X,Y coordinate. We're working on documentation, there's sadly not a whole lot, so looking at other people's code is your best bet.
Well, I used locate_OS (should be renamed to setCursor or setOSCursor) to do printing, and my ftoa function works on the prizm!
That aside, I am working on a project and I need to display a full-screen sprite. I looked at the difference between GoL/Minesweeper vs. Tetrizm/Obliterate - The latter actually hide the white outside border and the header/battery info. How is this done? I need to do full-screen drawing and am stuck with messed-up sprites.
GoL should do that, too. You basically just draw over it and don't call the key function that resets it up there--at least, that's how I think I did it. Poke Kerm and Ashbad to look at this topic, they know better about that stuff.
Just don't use GetKey(), And you'll overcome thé status bar
Ok, so how do I get key input then?
Hum... Should see thé useful routines topic
:-\ I will... I will start entering doxygen notes into the prizm SDK headers and cleaning them out so that functions are not repeated in multiple headers. I will start rounding up documentation and putting it in one location.
For GetKey, it draws the battery icon and handles the {MENU} button. key == 0 if nothing is pressed. GetKey, I assume, only blocks when you press menu, or does it? What is the return?
For clearing the VRAM, what is the difference between Bdisp_AllCr_VRAM and Bdisp_AllClr_VRAM?
Could I impose on all of you guys to please start documenting these on the new wiki? We really need everything that you're learning about these routines put up on the respective pages so we can have good, useful information when the wiki launches. Please PM me if you need the url and/or credentials for the wiki.
Edit: I voted "no" for DOxygen; better to keep expanding the wiki imho.
Link in your PMs if you PM me.
Ok, I was just wondering if I should use the doxygen as there are multiple SDKs, unless they all have the same function names
AHelper wrote:
Ok, I was just wondering if I should use the doxygen as there are multiple SDKs, unless they all have the same function names
The primary SDK in use right now is the PrizmSDK, which also inherits the (confusing IMHO) names from the mini and micro SDKs. I believe no one is really using Simon's miniSDK anymore.
ok, then doxygen is out, unless I can somehow get doxygen and wikipages synced. It's a large help when using VC++ (iirc), KDevelop, or other IDEs that reads and displays doxygen notes on functions (which is why/how I did the documentation for GlassOS)
AHelper wrote:
ok, then doxygen is out, unless I can somehow get doxygen and wikipages synced. It's a large help when using VC++ (iirc), KDvelop, or other IDEs that reads and displays doxygen notes on functions (which is why/how I did the documentation for GlassOS)
I wouldn't be surprised if there was some sort of tool to spider a wiki and generate DOxygen notes, to be honest, but there might well not be. Anyway, back to the topic at hand, let me know if and what I can clarify about using Prizm-specific functions, especially for key input.
Is there an alternative to GetKey that looks like it, smells like it, but doesn't display that border? (Same functionality)
AHelper wrote:
Is there an alternative to GetKey that looks like it, smells like it, but doesn't display that border? (Same functionality)
There are several excellent alternatives! I use two major methods, one of which allows the [MENU] key to return you to the homescreen, the other of which catches the [MENU] key itself and does not return to the homescreen. Lifted directly from Tetrizm (and please also consult the Useful Routines topic), first the routine that lets the OS interrupt when [MENU] is pressed; it blocks until a key is pressed with KEYWAIT_HALTON_TIMEROFF.
Code: while(gameactive == 0) {
//draw main menu here
Bdisp_PutDisp_DD();
GetKeyWait_OS(&kcol,&krow,KEYWAIT_HALTON_TIMEROFF,1,0,&key);
Bdisp_EnableColor(1); //<-- important!
if (kcol == 3 && krow == 2) { // enter
gameactive = 1;
}
if (kcol == 2 && krow == 9) {
mode = (mode == 0)?(NMODES-1):mode-1;
} else if (kcol == 3 && krow == 8) {
mode = (mode == (NMODES-1))?0:mode+1;
}
}
And also the routine that doesn't allow [MENU] to be taken by the OS:
Code: if ((key = PRGM_GetKey())) { //double parens because GCC wants them!
//key was returned
//These things don't get debounced
if (key == KEY_PRGM_MENU) {
gameactive = 0;
goto finishgamefree;
}
if (key == KEY_PRGM_DOWN) {
...etc etc etc...
For me, PRGM_GetKey is not defined. I know that it is in keyboard.hpp (why are there sooo many headers... for keyboard stuffs?!), but it fails to be linked in.
AHelper wrote:
For me, PRGM_GetKey is not defined. I know that it is in keyboard.hpp (why are there sooo many headers... for keyboard stuffs?!), but it fails to be linked in.
Sorry about that. It's a routine I put inline in all my programs:
Code: int PRGM_GetKey(){
unsigned char buffer[12];
PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}
I will add that in :-X
Is that buffer size required, or can it be smaller? Also, do bytes 1&2 check for the on key like byte 0?
No, the buffer has to be 12 bytes. I'm actually not sure about the answer to your second question, although I'd be interested to know.
Testing gogogo?
I know that byte 0 is 16 for every key press. Pressing AC/ON returns -16. Never checked the other bytes.
I need to see what all 12 bytes correspond to. Locale?
Also, I will be testing some functions from GlassOS (that I couldn't use) (wink) for a project of mine (wink).
(wink)
