/taspringdevfolder/rts/glList.cpp
-----------------------------------------
void CglList::Draw()
{
glDisable(GL_TEXTURE_2D);
glLoadIdentity();
glColor4f(0,0,0,0.5f);
glBegin(GL_QUADS);
glVertex3f(0.3f,0.1f,0);
glVertex3f(0.7f,0.1f,0);
glVertex3f(0.7f,0.9f,0);
glVertex3f(0.3f,0.9f,0);
glEnd();
glEnable(GL_TEXTURE_2D);
glColor4f(1,1,0.5f,0.8f);
glLoadIdentity();
glTranslatef(0.31f,0.85f,0.0f);
glScalef(0.035f,0.05f,0.1f);
font->glPrint(name.c_str());
std::vector<std::string>::iterator ii;
/****************************************
* Insert Robert Diamond's section here *
* <deadram@gmail.com> *
****************************************/
/****************************************
* TODO: *
* *
* This part of the code will need some *
* math, and it's been a while since I *
* did any 3D coding... the idea is to *
* keep the selected item in the middle *
* 60% of the screen, but don't scroll *
* till we reach one end, or the other *
* of that boundary. We'd also need the *
* "oldPlace" variable to do this *
* properly. *
* *
****************************************
// Get screen res, so that the selected item is always within the middle 60% of screen
int iResX = regHandler.GetInt("XResolution", 1024);
int iResY = regHandler.GetInt("YResolution", 768);
// Keep tabs on the last place. change this ONLY AFTER a scroll
static int siOldPlace = place;
if (we're scrolling up) siOldPlace = place;
if (we're scrolling down) siOldPlace = place;
if (we're not scrolling) siOldPlace = siOldPlace;
**************************************
* Hey remove me when TODO is done XD *
**************************************/
int nCurIndex = 0; // The item we're on
int nDrawOffset = 0; // The offset to the first draw item
// Get list started up here
ii = items.begin();
// Skip to current selection - 3; ie: scroll
while ((nCurIndex + 3) <= place) { ii++; nCurIndex++; }
for (/*ii = items.begin()*/; ii != items.end(); ii++)
{
if (nCurIndex == place) {
glColor4f(1,1,1.0f,1.0f);
} else {
glColor4f(1,1,0.0f,0.3f);
}
glLoadIdentity();
glTranslatef(0.31f, 0.79f - (nDrawOffset * 0.06f), 0.0f);
glScalef(0.035f, 0.05f, 0.1f);
font->glPrint(ii->c_str());
// Up our index's
nCurIndex++; nDrawOffset++;
}
/**************
* End insert *
**************/
}
------------------------------
At present the selected item is *always* drawn as the 3rd item in the list (with 2nd and 1st being exception).
This line ~could~ be changed...
glTranslatef(0.31f, 0.79f - (nDrawOffset * 0.06f), 0.0f);
to some variant using nCurIndex, place, and maybe an if statement, but by leaving nDrawOffset the code is more readable. In any case the compiler will probably *efficient* the variable out for "small code" and leave the variable in (INC is cheaper then a math equation) for "fast code" options.
I don't want to bother with a diff, so your going to have to find out what my changes are yourself :P
If anyone has CVS access and can update the file, I wouldn't care, but other people might like to have my ~scrolling~ feature added to thier exe.
More stuff to come, soon as I get around to it :P
PS: Feel free to flame me, I don't like to read, so I dono if this already exists in the lastest version of the code.
PPS: Ummm... fix the CGI to include tabs XD
new glList code to implement ~scrolling~
Moderator: Moderators
A poll eh?
You can, just move the slider in the lobby, and if you're doing a directIP game change the value in script.txt and feed the file in to spring.exe as its only parameter.I think you should start with 1000/1000 resources :D
Ah yes it does doesnt it. But then I'm in the process of writting it and so are others.I think the AI needs improvements
In a months time people wont have any need for spawn files. If I havent released my Skirmish AI, zaphod will have released his.I think there should be a way to "select" spawn.txt files
Meh, I was just thinking single player would be much nicer with buttons and click noises and a nice litle interface to select the resource startup and side (arm/core) and such. Don't know were to start, so vote, and I might get off my butt XD It'll look more like a professional game with a 3D interface, to accompany the already professional 3D game play :) Sides, buttons and text boxes and sliders are about the easiest thing to implement, and changing a value or 5 is the easiest thing to change XD
3D implementation of the GUI could slow the compiling down and pregame selections, and it would add an extra chunk of code to maintain, but it doesn't have to slow the game play down. The 3D GUI objects don't exist throughout the game, once thier done and the last click has been made, that memory is free'd and the game starts.
As long as the GUI objects access pre-existing code, it shouldn't complicate the code to much. My plan is to add an extra 'script' selection, say "3D interface". If done this way, there shouldn't be a need to change anything in lesson2, or any other file, so all the changes will be separated from the original code. I'll have to find out how mouse movement and key pressing trickles down the event handler, but as I understand it, these events should end up in the right spots. The only other problem I see is that this 'script' has to run, then start a different script, set variables, and end. I might end up making a copy of the "spawnscript" code block to simplify the interface code.
As long as the GUI objects access pre-existing code, it shouldn't complicate the code to much. My plan is to add an extra 'script' selection, say "3D interface". If done this way, there shouldn't be a need to change anything in lesson2, or any other file, so all the changes will be separated from the original code. I'll have to find out how mouse movement and key pressing trickles down the event handler, but as I understand it, these events should end up in the right spots. The only other problem I see is that this 'script' has to run, then start a different script, set variables, and end. I might end up making a copy of the "spawnscript" code block to simplify the interface code.
Meh, what would I need to change in the code... Select the "interface" script, it get's started, it runs it's menu, it destroys it's menu, it starts a single player game. What part of this would have to interact with the existing code? Sure I'll need to access global variables and objects, but the other scripts already ~need~ to do that to start a game. Sure I'll need to draw stuff to the screen durring the selction process, and that's the part I'll have to code. All the interface is doing, is giving a nice drawing of the start-up variables and letting the user click them to thier like'in. Apart from a "pause" in the start-up process to bring up a menu, and then a few Get's and Set's for the variables, not much is being done. I could just force the interface on people and mix it with the lesson2 code block, but that would chage the rest of the code. All I'm planning on doing is adding an extra selection to the first glList (if we're in single player XD), and then copying and pasting the spawnscript code into say spawnInterface, and adding the 3D interface in that file (and well, glButton, glTextBox, glComboBox, etc...), as it's own object.
When you select a script from the main menu, it loads the game, runs the script, initialises the interface, at which point we can usually see a minimap and a landscape.
So what you're saying is you're gonna take all the game interface code and the OpenGL stuff that displays all our untis etc, duplicate it, and stick it in a script, then start changing the GUI to do whatever it is you wanted todo so that the main code isnt changed?
Cant you just Set a global variable such as bool 3DInterface; and tie ti in with settings.exe? That was users can turn it on and off.
So what you're saying is you're gonna take all the game interface code and the OpenGL stuff that displays all our untis etc, duplicate it, and stick it in a script, then start changing the GUI to do whatever it is you wanted todo so that the main code isnt changed?
Cant you just Set a global variable such as bool 3DInterface; and tie ti in with settings.exe? That was users can turn it on and off.
That zwzsg, seems a lot simpler, Make the AI autoload GroupAI that ahve the same filename as the map your loading, that map would hold a Skirmish AI with a script interpreter, and thus would also ahve a script defining the mission and having the ability to influence and change the way the skirmish AI works.
Of course all of that is dependant on wether the engine laods these AI...
Other useful additions for missions would be GAIA player, and arbitrary startup scripts rather than just the commanders.
Of course all of that is dependant on wether the engine laods these AI...
Other useful additions for missions would be GAIA player, and arbitrary startup scripts rather than just the commanders.
I see were I went wrong, sorry XDAlantai Firestar wrote:<snip>...</snip>
Cant you just Set a global variable such as bool 3DInterface; and tie ti in with settings.exe? That was users can turn it on and off.
"pregame" needs to be given a makeover...
so I can make a "pertypregame" and add this to lesson2:
Code: Select all
if ( regHandler.GetInt("pertypregame", 0) ) // default off
{
pregame = new CPertyPreGame(server);
} else {
pregame = new CPreGame(server);
}
If you know how to, could you tell me a nice way to read input from the mouse? CPreGame can already get keyboard input, but I don't see an easy way to get to the mouse, yous know more about the code then I do :)
Hummm....
lesson2 only needs the mentioned change
pregame.h needs "#include <pertypregame.h>" at the top. This will make it easier to remain compatible with future changes to pregame.
Class CPertyPreGame: public CPreGame
{
... overidden methods go here
... GUI objects go here:
... CglPertyButton m_glButtonDone;
}
I think that will keep the code clean and managable.
But... now that I've seen the settings code :P
We're going to need some funky stuff in there, it's MFC so why not abuse that fact? tooltips, "number text" tooltips for LOD/details scrollbars. How 'bout property pages? Meh, I'll see what I can wip up today.
lesson2 only needs the mentioned change
pregame.h needs "#include <pertypregame.h>" at the top. This will make it easier to remain compatible with future changes to pregame.
Class CPertyPreGame: public CPreGame
{
... overidden methods go here
... GUI objects go here:
... CglPertyButton m_glButtonDone;
}
I think that will keep the code clean and managable.
But... now that I've seen the settings code :P
We're going to need some funky stuff in there, it's MFC so why not abuse that fact? tooltips, "number text" tooltips for LOD/details scrollbars. How 'bout property pages? Meh, I'll see what I can wip up today.
MFC??? no no no no no no no. It's in our interests to code the program so that it can be integrated into spring in pregame.
Although, if you created a second version of the program that acted like a wizard and walked you through and selected the best settings and let you change them, you know explain, it could be called once installer has finished or on first run...
Although, if you created a second version of the program that acted like a wizard and walked you through and selected the best settings and let you change them, you know explain, it could be called once installer has finished or on first run...
I commited the gllist changes to the CVS. If you want to create some sort of more advanced interface to the game start you are probably better of subclassing from CGameController directly instead of pregame. For mouse support you would either have to initialize the standard CMouseHandler or make that one inherit from an abstract base class that you also create a CPreGameMouse from.