This is the Client skeleton I've been working on.
Latest Source available on request :)

The game menu system is implemented via my GameMenu oop class.
Each "menu page" contains from 1 to 4 menu items, whose texture is sourced from a common image (ie, one bmp, jpg etc = 4 items).

TextureLoader is implemented, but only one page of menu implemented visually.
Currently I load that one texture from a JPG which is embedded in the exe resources.

Have a nice day :)

Posted on 2005-07-15 02:18:09 by Homer
The last version of the application created an instance of TextureLoader and used it to load a jpg from resources, into a static glTexture structure (in .data segment).

I just implemented TextureManager derivation of TextureLoader, ostensibly to keep a DataCollection of loaded glTexture structs allocated on the Heap.
It doesn't work, and I've seen this before.

My belief is that OpenGL detects if the receiver for a textureid is within the exe's memory range, and denies it if it isnt.

Tomorrow I'll confirm this by replacing the heap struct with a static one, and then on success, copying the data to a heap struct.

If it works, it means I just discovered what I believe is an undocumented "feature" of OpenGL, that it refuses to load a texture to a receiver which is outside the exe's loadtime memory range.

If thats the case, I'm pissed off, I don't need my hand held by opengl :(
OK fair enough, OpenGL is DLL based, and it isn't aware of runtime memory, but so what?
I'd rather crash and burn than have OGL perform sanity checks on my behalf :|
Posted on 2005-07-15 06:03:57 by Homer
I was wrong about that.

I've got the TextureManager working correctly.
The issue was in the TextureLoader - certain fields must be NULL for certain calls to succeed, and I wasn't ensuring they were NULLed.

Here's an update of the Client..
In this version, the menu textures are loaded as the menu is constructed, from jpgs embedded in resources of the exe.
We simply declare either a ResourceID or a ptr to a ResourceName whenever we create Menu nodes :)
The GameMenu class routes its texture loading through the TextureManager, whose job is to ensure that textures are loaded once, no matter how many times they are referenced.
In fact, as I mentioned in the previous post, TextureManager class derives directly from TextureLoader, in other words, TextureManager IS TextureLoader, with extra stuff :)
TextureLoader operates on a custom struct called glTexture.
TextureManager adds a "DataCollection" of glTexture structs to the existing functionality of TextureLoader, ie, it gives TextureLoader the ability to remember which textures its already loaded, creating a "bank" of loaded textures...

Updated : Better handling of Window Resize.
Known Bugs : Textures not reloaded when FullScreen/Windowed mode is toggled (F1)
? ? ? ? ? ? ? ? ? ? ?Red component of textures screwy when FullScreen is selected as initial window ??!?
                    MouseCursor Particle size not scaled with Window ;)

Posted on 2005-07-16 03:58:13 by Homer
Latest news is that I realized I can force an OpenGL Orthographic Projection's Y coordinates to match Windows (topleft zero instead of bottomleft zero).
This is performed by simply switching the upper and lower threshold values for Y in the call to glOrtho, so instead of going from 0 to screen height, we go from screen height to zero..
the immediate result is that everything is drawn upside down, ie flipped in Y , which looks crazy :)
I had to rewrite my 3D code to flip the UVs, and the upside to all of this is that I can now make sane and fast 2D mousepicks, ie, I can click my menus :)

Go Crazy :D

oh bummer, forgot about the particles Y ..
Posted on 2005-07-16 18:24:48 by Homer
I dumped the crapola particle snippets.
I wrote a ParticleSystem class, and implemented it.
I made some small improvements to TextureManager and TextureLoader.
BMPs are now able to be loaded from resource, but you MUST specify a ResourceName, and not simply a ResourceID. Aside from that quirk, everything's peachy (in Windowed mode at least)
Posted on 2005-07-18 04:00:33 by Homer
I dumped the crapola Menu snippets.
I reworked GameMenu so that I can now specify the screen coordinates and texture UVs for each MenuItem on a GameMenu page.
I also improved the MouseClick detection, which is several orders faster as a result.
I also implemented an "antiscaling trick" so that mouseclicks are accurately detected no matter what size the window is running at..
You see, when the window is resized, I calculate the "Resize ratio" from the initial window size and current window size. This ratio is then applied to MenuItem geometry on the fly during rendering, such that MenuItems are scaled to the window size.
All the real 3D stuff like the particles gets rescaled by OpenGL, we just need to worry about the orthographic stuff.
Uploaded an updated exe to URL in previous post..
Posted on 2005-07-19 12:03:05 by Homer
Who cares?
Posted on 2005-07-20 08:11:10 by Homer
Registration error-Start Debug center manually
If run in full-screen after the error my cursor has disappeared so I used esc to get out. If not in full screen mode it renders a black window. Task manager shows 50% for this also.

Posted on 2005-07-20 08:39:15 by lostcauz
Works for me, but I think the particles are still waaaay too fast ^^"

I tried to copy you the output (it's shoing some failures), but DebugCenter crashes every time I select the text and press RMB, saying "couldn't find 'calculator.exe' " :|
Posted on 2005-07-20 10:41:37 by ti_mo_n
I keep getting the same error too, whether it is full screen or not. What does it mean?
Posted on 2005-07-20 11:16:51 by roticv
The failures are due to some menu images being missing from your exe resources - disregard them, I'm waiting on my 2D artist to throw some decent looking textures together for me.

As for the speedy particles, it appears that my GETELAPSEDTIME function is quirky.
I'll replace it with a snippet to calculate elapsed times on the fly based on GETAPPTIME.

I've added a snippet of code to the GameMenu class, so that MenuItems can be rendered with a sinewave effect, which looks kinda weird, and hopefully, will look ok once I shove a big fat rotating texture behind it all...

Anyhoo, I added some "dummy" textures to resources, and all the errors go away, which is cool..
I've not had a chance to re-upload the client yet, so wait another day please, I'll let you know when I've re-upped.

Basically I'm happy with GameMenu now, I can reuse it for "in-game menus" at my pleasure, and I can specify the 'subtexture coords' (UV) and Window coords for each and every Menu Item of each and every Menu Page, and any MenuItem can be associated with a callback function, and/or a SubMenu, and all of this will be rescaled at render time to suit window size.. good stuff :)

Methinks I'll post some of the support classes shortly, everything is modular ;)

Guys - thanks for the feedback, I am developing this stuff on a 333 with no graphic card, so it's very hard for me to visualize what happens when the framerate soars.. my 'daily driver' still has not been replaced :(

Victor - many thanks for the hosting, if/when you require my time, it's yours, I am indebted to you.
Posted on 2005-07-20 11:33:01 by Homer
I?m curious about the failure of the DebugCenter opening Calc.exe. Can somebody tell me where in your OS?s Calc.exe is placed and which OS you are using?
BTW, in the current version of DebugCenter, the RMB is reserved for sending the selection to the calculator. Perhaps a better idea is to popup a context menu...  8)


Posted on 2005-07-20 14:37:17 by Biterider
Win2k SP2,  c:\winnt\System32\calc.exe . RMB doesn't find it, but no crashes happen. Ctrl+A Ctrl+C work fine, timon

How about the attached image - for a temporary one till your 2D artist comes up with a design :)
I like designing textures for games, so maybe I can help with that ? Experience is what I need, to become a good designer :)
Though, I can't help with code - ARM with direct screen access is my domain ^^", and I like to work on complete projects that have a pinpointed design right from the start.
Posted on 2005-07-20 18:08:54 by Ultrano
WinXP SP2, latest patches, etc, etc.  C:\windows\system32\calc.exe
Pressing RMB pops up the error and hangs the debug center (it's not responding for few seconds, and then the OS ghosts the window, so I can close it).

Ctrl+A Ctrl+C work fine, timon

^^" I should think sometimes :P

As EvilHomer2k said, it just complains about image resources :)
Posted on 2005-07-20 18:41:42 by ti_mo_n
Ultrano - sweet, I'll take you up on the offer for temp? artwork.. I'll require 512x512 menu textures, currently I assume there's four items per texture as you have realized, but you'll need to stretch the text in Y, such that it consumes all the vertical space for each menu item.. Leave X as it stands.. a few blank horizontal rows is ok, but not as much empty space as you currently have there..
Since I apply quarter of the texture to each menu item, and I draw them apart from one another, using all the Y space simply means more texels - more potential detail. Don't worry if it "looks weird" on the texture..
If I apply your demo texture, the text looks "squashed in Y", and it makes more sense to stretch the texture, increasing the texels, than it does to sample smaller subtextures..

I've re-uploaded the exe with some "dummy textures".
MouseClicks are now handled in a very simple way, and seems fine.
More importantly, my "antiscaling" trick worked, and MenuItem mousepicking is accurate no matter what the window dimensions are.

Just as a sanity check, here's the current menu structure:

1 - Single Player
2 - Multi Player
3 - Options
4 - Quit

1 - Player Settings
2 - Video Settings
3 - Go Back

1 - Resolution
2 - WindowMode toggle
3 - Go Back

Note that ANY MenuItem can have a submenu, I just didn't require a more elaborate menu at this time.
Note also that GameMenu is oop, and I can create "in-game menus" with this too, which obviously would be dimensionally smaller, although potentially deeper..

Have a nice day :)
Posted on 2005-07-21 00:21:19 by Homer
I've uploaded an updated exe.
Found the problem with particle speed and elapsed times and fixed it.
There was nothing wrong with the elapsed times, it was a bug in the particle physics.
I've slowed down the particles a LOT in this version, just to proof-test some changes to the particle timing code:
I've changed the way the Particle TTL works .. instead of declaring the particle lifespan in seconds, I now declare the particle lifespan as a float from 1.0 (alive) to 0.0 (dead), and declare a DecayPerSecond for the particlesystem.
The reason is because I use the Particle.Life value as the Alpha blending factor.

I'm going to re-enable the clientside network code shortly..
Posted on 2005-07-21 16:53:47 by Homer
I've updated the exe again.

Added a big animated texture behind the menu.
Trilinear filtering is enabled for menu textures and the particle texture.
Looks much nicer :)

What do you think?
Posted on 2005-07-21 23:04:33 by Homer
Looks nice  :)
Posted on 2005-07-22 00:05:58 by Biterider
OK, now I see what was intended and it works correctly. Looks very nice. Great job!  :D
Posted on 2005-07-22 00:36:55 by lostcauz
WOW, the particles finally work! :) Are you drawing them as the point-srpites, or stadard 2 triangles? And they are too opaque near the borders - I can easily see that they're squares.

Nevertheless, tehy look nice ;)
Posted on 2005-07-22 16:06:36 by ti_mo_n