[WIP] Sabacc Basics

[goumba]

For the Star Wars fans, a PSP version of Sabacc, still in progress, however. It took me about a year to get it to this playable point, as I only get about 2 hours a week to work on it.

I know there's some bugs:
- The biggie: It will crash after a few rounds. This is actually caused by a call to strlen at some point, each time from somewhere else in the program. Therefore, it's pretty much random. I haven't had too much time to analyze libc.
- When starting a new round, the text in the middle of the screen which tells you the selected card is not updated (oops, forgot this one, I don't know how).
- Probably other stuff I can't think of right now.

Other issues:
- There's no artwork for the face cards, so all you'll see is the name of the card. Volunteers welcome, I'm not a great artist.
- Menu lacks help. Up/Down to select. X to confirm.

Try it here, and let me know what you think (firmware 3+).
http://rapidshare.de/files/40456456/...3-psp.zip.html

[TurtlesPwn]

(you forgot the link)

[_df_]

Originally Posted by goumba

I haven't had too much time to analyze libc.

I can garuntee the bug is in your code, not the libc.

sounds like spurious memory (double free or using more than you allocate).

use valgrind or electric and see what it says.

[slicer4ever]

agreed with _df_ it's most likely that your trying to use more than what u have given the program to use, but without seeing the code it's all speculation

[yaustar]

I would guess either you have passed strlen a NULL pointer or a non NULL terminated string.

[goumba]

I thought of that. The same code does NOT crash on Ubuntu 7.04 and newer, and it's been critical of any double frees or the like to this point.

If I used a C style string and went past the last element, Ubuntu responds with terminating the program with a stack smashing message.

Ditto for double free. Neither of these occur at all under Ubuntu. Now I realize the PSP doesn't have the kind of protection that Ubuntu may offer their libs, but I thought in the two cases mentioned I'd run into them at some point.

Using psplink and psp-addr2line, I always get the results

basic_string
char_traits.h: 57 - which is length() and which itself calls strlen to get the length.

Of course I was thinking too hard and now I've been enlightened and will take another looksee.

Anyway, sorry for not including the link, it's now back in the first post. Laptop battery died as I was posting before work and I couldn't find the charger.

[yaustar]

Are you using the Standard C++ Library and std::strings? If you are, I hazard a guess at memory fragmentation depending on the data and/or containers you have used and how you used them.

[goumba]

yaustar,

Yes, I am using STL. I use std::string, vector and map in my program. I created a simple widget toolkit for display elements for the game, and in the case of a Text Label object, it contains a std::string member, which may over the course of the program get changed a lot. In this light your suggestion makes sense, and I'm going to do some reading now. My Stroustrup and STL Reference books make no mention of it that I remember, I'm gonna have to go a-googlin' for remedies.

__df__ I am somewhere between a novice and intermediate programmer. I have no formal training, yet I have no problems with C++. I have tested the linux elf with valgrind the whole time of development, and the only errors I got were in regards to SDL and X11 libs, and none involving any of my code at this point (I have had to correct a two or three memory leaks in the past). I'm going to give electric fence a shot later as well. I'm just saying I'm aware of the tools you mention and they have been used. And like I said, the Linux binary doesn't suffer the same as the PSP binary does. Unfortunately, I guess being between novice and intermediate, if I see an function causing the error where it didn't on the other platform (in this case one in the STL calling that of libc), I needed someone like you to slap me in the head to wake me up not is all it seems. Hopefully I'll get to the bottom of it.

[yaustar]

The PSP has limited memory of 32mb compared to your PC's 1gig+ which means that you hit fragmentation issues earlier.

One suggestion is to use the reserve function when you instantiate it to allocate a chunk of memory that is big enough to fit your longest (most common?) string. This way, it doesn't keep reallocating memory when it has to store text that is longer then the currently allocated buffer.

Eg.

std::string buffer = "";
buffer.reserve( MAX_FILENAME_SIZE );

http://www.cppreference.com/cppstring/reserve.html

Ideally, a fixed length string class would have been useful but STL doesn't have one .

The strange part is that it crashes in strlen rather then any allocation method. If we could get the whole call stack, it would be useful.

[goumba]

Originally Posted by yaustar

The PSP has limited memory of 32mb compared to your PC's 1gig+ which means that you hit fragmentation issues earlier.

...

The strange part is that it crashes in strlen rather then any allocation method. If we could get the whole call stack, it would be useful.

I know the PSP has such limited memory which is why I've worked with valgrind from the start, to catch any issues. Better get them earlier than later.

Anyway, when you ask for a call stack I take it this is what you want from PSPLink (new to debugging on PSP, so I'm not exactly sure of all PSPLink has to offer)?

Exception - Bus error (data)
Thread ID - 0x04634775
Th Name   - user_main
Module ID - 0x04657665
Mod Name  - SDL App
EPC       - 0x08AAD0E4
Cause     - 0x1000001C
BadVAddr  - 0x31CA7142
Status    - 0x20088613
zr:0x00000000 at:0x0008FF00 v0:0x501D8001 v1:0x088FF138
a0:0x501D8000 a1:0xFFFFFFFF a2:0x088FF138 a3:0x00000000
t0:0x08C1D144 t1:0x08CA0C60 t2:0x00000000 t3:0x07E0F81F
t4:0x00000000 t5:0x00000018 t6:0x0000005F t7:0x0000001F
s0:0x501D8000 s1:0x088FF138 s2:0x088FF13C s3:0x088FFEE0
s4:0x00000012 s5:0x00000013 s6:0xDEADBEEF s7:0xDEADBEEF
t8:0x0000005F t9:0x00000340 k0:0x088FFF00 k1:0x00000000
gp:0x08B38D70 sp:0x088FF100 fp:0x088FF110 ra:0x08982D68
0x08AAD0E4: 0x90830000 '....' - lbu        $v1, 0($a0)

host0:/> !psp-addr2line -Cfe sabacc.elf 0x08AAD0E4 0x08982D68
strlen
??:0
basic_string
/home/anthony/tmp/psptoolchain/build/gcc-4.1.0/build-psp/psp/libstdc++-v3/include/bits/char_traits.h:257

Anyway thanks to you I decided to go a step further, and play with psp-gdb for a backtrace. Never tried before, figured it would be a bit of work. Boy was I wrong, what a piece of cake. Anyway, I got:

Program received signal SIGBUS, Bus error.
0x08aad0e4 in strlen ()
(gdb) backtrace
#0  0x08aad0e4 in strlen ()
#1  0x08982d68 in basic_string (this=0x88ff13c, 
    __s=0x7d000001 <Address 0x7d000001 out of bounds>, __a=@0x88ff138)
    at char_traits.h:257
#2  0x0894f248 in CardImage::draw (this=0x8fab720)
    at src/sitextensions/CardImage.cc:88

CardImage.cc (much more readable in emacs as everything fits on its own line)

86: getCardFont().render(face_names_neg[value + neg_offset],
87:            getSurface(),
88:            (getWidth() - getCardFont().lineWidth(face_names_neg[value + neg_offset])) / 2, getCardFont().getLineSkip());

face_names_neg is an array of c-style constants. lineWidth(...) takes an std::string by value, but no where does it call std::string::length() directly. It uses an iterator to go through the string, applies any formatting via codes in the string, and computes the character's size to be rendered, adding it to a total (I'll post that if you like, but this is long as it is already).

Maybe I need to write a version of lineWidth and render dealing with only c-style strings. However if I do that for the text rendering code the compiled code will get a bit bigger, but I'll do what I need to (and make Scott Meyers happy with fewer implicit conversions ).

[yaustar]

What datatype is face_names_neg? char *? If it is, why not store it as std::strings?

What is the function prototype for 6: getCardFont().render?

Looking at the code, I be inserting some extra code to check if value + neg_offset is within bounds of the face_names_neg array just to see if it is causing the crash.

[goumba]

face_names_neg was const char*, now const std::string.

The prototype for render is:

int FreeTypeFont::render(std::string, SDL_Surface*);

The idea was to allow for implicit conversions in case I used a c-style string somewhere. I think maybe this would be better off passing by reference than by value.

A check has always been place to make sure that is within the bounds of the array.

[yaustar]

If you do need a const char * string, std::string has a function to return it's string as const char *.

std::string test = "dfklsdfjklsdf";
const char * blah = test.c_str();

http://www.cppreference.com/cppstring/c_str.html

[goumba]

Thanks, I know about c_str().

I don't need c-style strings, in fact I'd rather avoid mixing them with std::string in the program. They were c-style for some reason long forgotten, and are no more.

[yaustar]

Does the program still crash?

[goumba]

I hope to get a newer version uploaded in a while, but no, it no longer crashes.

[goumba]

New link posted in the first message. It no longer crashes, and added a new game mode (Casino Game was the former "New Game" and added "Standard Game").

I tried to repost the link here so that viewers didn't have to go back to the first post, but got a message to avoid spammers you now need 10 posts to post a link. #@%# spammers.

[dan369]

Yeah, thats just how it works (though i thought it was 5 posts Oh well) is this written in C or C++?

[_dysfunctional]

It obviously isn't C, so take a guess

[dan369]

i had a feeling it was C++ lol

[goumba]

It is mostly C++ except for the SDL part.

[goumba]

New version (in first post, still cannot post links).

What's new:
- In both games, when you attempt to call, you would get the message "Can't call before the fourth round," press X to continue, BAM! return to the title screen. A misplaced "return" caused this and has been fixed in the Casino game only. Standard Game still suffers this bug, it's not done, and you shouldn't be playing it.
- The dialog boxes and cards used to show the background around the edges of the text and now his has been fixed - for the dialog. Most other text now show a translucent box around the text.

Fix one thing, and now more stuff needs to be fixed that didn't before.