ah a friend of mine told me that playing the game in his win2k, all the game window was going very slow updating, also when moving it along the desktop it leaved artifacts on screen. maybe you better keep off the window shadow…
yeah there are a few priority tweaks that need to be made yet 
Okay, this is just a programming question, and is likely to not get answered, but i figured i’d ask it anyway…
I’ve got the highscoretable system working, and it’s easy enough to just get a simple high score table with just points [there’s one included], but a bit more complex if you want to make your own multiple-table system.
The squares game, for instance, has [points] and [squares]. It’s not finished yet, but if you’ve played the original you’ll see that the points can zoom up thanks to the power ups, but you can still have a low number of squares! Just storing by points then isn’t enough - you could have 20 games with really high scores but only a low number of squares - losing out on a record of ‘that game where you got 300 squares but somehow less points than all the other games put together’.
So, here is the code that defines the custom tables for the squares game:
class SquaresHighScore : public HighScoreEntry
{
public:
class PointScore : public HighScoreValue<int>
{
public:
int compareElements ( HighScoreEntry* first,
HighScoreEntry* second );
}
pointScore;
class SquareScore : public HighScoreValue<int>
{
public:
int compareElements ( HighScoreEntry* first,
HighScoreEntry* second );
}
squareScore;
SquaresHighScore ()
{
pointScore.setValue (0);
squareScore.setValue (0);
}
int getPoints () { return pointScore.getValue(); }
void setPoints (int value) { pointScore.setValue (value); }
int getSquares () { return squareScore.getValue(); }
void setSquares (int value) { squareScore.setValue (value); }
};
int SquaresHighScore::PointScore::compareElements (HighScoreEntry* first, HighScoreEntry* second)
{
int f = ((SquaresHighScore*) first)->getPoints ();
int s = ((SquaresHighScore*) second)->getPoints ();
if (f>s) return -1;
else if (f<s) return 1;
else return 0;
}
int SquaresHighScore::SquareScore::compareElements (HighScoreEntry* first, HighScoreEntry* second)
{
int f = ((SquaresHighScore*) first)->getSquares ();
int s = ((SquaresHighScore*) second)->getSquares ();
if (f>s) return -1;
else if (f<s) return 1;
else return 0;
}
// HighScoreTable template params:
// First is the HighScoreEntry subclass used for each entry in the table
// Second is the relevant value in the entry to be recorded and sorted
typedef HighScoreTable<SquaresHighScore,SquaresHighScore::PointScore> HighScores_Points;
typedef HighScoreTable<SquaresHighScore,SquaresHighScore::SquareScore> HighScores_Squares;You might be able to figure out what’s going on there - the entry type has embedded classes which are used as ElementComparators, and they have their compare functions defined to check the instance of that type within the entry.
Now, i know this is a very odd way of doing things, and would probably make some programming professionals/tutors puke into their beards. But do you think it’s reasonably acceptable to do it this way? With this system, i can have a HighScoreTableManager with a simple ‘addScoresToEntry’ function, which can then attempt to add the score to any registered high score tables automatically. Granted, it’s a little tricky to set up your own table classes, but it’s got an obvious pattern to it and can be done using cut/paste from an example like this. And, when it is done, you don’t have to worry about actually coding the table stuff in the game.
So, the question it, should i be shot for having it done this way?
I’ve decided that, even if it’s of little or no interest to people here, i’m going to use this thread as a blog for this project 
That way i can keep track of it myself, but also y’all can take a random peek in and see how it’s progressing.
Today i’ve been trying to finish off the high score table system.
I’m actually pretty pleased with the high score table system now. Even though it does use some odd coding practise, it’s pretty neat the way you can just carefully define a HighScoreEntry type and it will just slot into the program and be fully functional. That system is pretty much done now.
-
HighScoreManager is a base that the GameComponent can inherit. It has a virtual function ‘prepareHighScoreEntry(HighScoreEntry*)’ where you add all your game’s score details to the provided entry type.
-
You create whatever HighScoreTable objects you require, and add them using ‘addTable(HighScoreTable*)’
-
At the end of a game, you simply call ‘addCurrentScoreToHighScores()’ and it will do all the work for you. It will attempt to add it to all the registered tables, and it will pop up a name entry dialog box if it will go into any of them.
-
The scary looking system in the previous post is only really if you need multiple tables providing different views on scores. If it’s just ‘points scored by this player’, or even with more information but only sorted by score, you can simply use BasicHighScoreTable, and subclass BasicHighScore to customise the data stored.
-
The tables are automatically written to and from Xml structures.
So, it’s only complex if you need a complex table system. But, because it’s done in this way, the complexity is restricted to only the design of the score entry class - the actual game code does not change at all. Plus, it is really really easy to do just a basic high score table now.
Now i can get back to doing more interesting stuff!
Bah! I suggested having an OpenGL renderer context to render all of juce into as it would allow perfect effects and so on and so forth in real-time, I was near instantly blown off…
Although I would have this finished being ported to Ogre (OpenGL and DX renderer layer combo) if this was a compatible license (lgpl, or at least something that is not so incredibly restrictive as gpl, I already have most of it done, juce makes it quite simple, but will never be released off of my computer unless compatible).
i didn’t blow you off! i’ll be making an OpenGL context for it, but there are a number of other things i wish to get working first (that have pretty much nothing to do with display, e.g. the highscore table stuff, different game states etc, saving/loading of settings)
i’m going to get as much of it done as i can before i have to learn something new (i.e. openGL) because i expect that will take quite a chunk of effort :’(
y’know when you think you should probably refactor stuff to make it more flexible…
…and you spend hours working on a different structure for your system, convinced it’s better…
…and then you realise that it’s actually more complicated than you’d expected it’d be…
…but you still have the belief that it was ‘wrong’ before, and should be changed…
…and then you find yourself in a limbo trying to decide what avenue to commit to…
As stated, I’d already started porting it to use OGRE, if completed then you’d have a renderer context for Windows, *nix, and Mac in OGL and D3D…
As stated before those, it is LGPL, as are all things required to link with it…
sounds interesting tho! i’ve yet to look into that stuff, but at the moment the main engine is having an overhaul.
one of the main reasons for this is to allow the actual ‘Component’ part to be separated from the game; with a base GameDisplay, different kinds would be able to be switched in and out. in theory. i’ve got a few days off work so i’ll be able to do some more soon…
Hi haydxn. I’d love to have a look at your GameEngine … but haydxn.net seems to be dead.
Is it available somewhere else? thanks!