Not much going on around here...
here's my old 2D MazeGenerator, reworked for 3D Mazes, as I claimed it could be? !!!

This version only generates 3D Cubic Mazes, but you can specify the PerDimensional Size from 1 to 256 Cells.
IE, Size 20 = 20 * 20 * 20 = 8000 Cells.

I also reworked the MazeGen algorithm.
The 2D version was a purely "DFS" (Depth-First Search) based algo. You can imagine that in 2D, or in 3D, as a "tunneling" algorithm.
At each iteration of the generator, a new cell was selected from the unvisited neighbours of the current cell, which then replaced the current cell, unless we ran out of unvisited neighbours, in which case a random cell was selected.. potentially a bad selection, wasting iterations.
We can say that, unless we "trap ourselves", the chances of "branches" is zero.
In 3D, it would tend to create one large tunnel consuming most of the world space, with perhaps one or two short side branches... not an interesting enough maze.
In the current version, at each iteration of the generator, the current cell is selected from a list of "cells which have been visited", and if the cell has no "unvisited neighbours", it is removed from the list, and the process repeated. Otherwise, an "unvisited neighbour" is selected.
We can say that the chances of "branches" is 100% at any time.
This generates "spiderweb" mazes which tend to contain "pockets" but are far more interesting.
A better algorithm would involve some probability which blended the two algos, so that it "tunnelled" and "branched" based on a calculation involving randomness.

Anyway, this won't be visually stimulating, it's a Proof Of Concept, and a Beta.
I'll add some OpenGL visualisation code as soon as I get some feedback.

Please try some different Maze Sizes in the sourcecode and rebuild/betatest and respond !!



In this demo, the Walls (including Ceiling and Floor) are encoded into 6 bits of one byte per Cell.
A further bit is used during Generating, to signify "VISITED" Cell, but essentially two bits remain unused per Cell - can you think of a good use for them?

At the end of the demo, the Cell Array contains Walls flag bytes which describe which Walls are present within each Cell of the 3D Maze - this array can now be saved to disk, etc.
The "CellID" field of the Cell struct is not required and can/should be eliminated from the source, leaving the Cell array as a 3D byte array :)
Attachments:
Posted on 2005-07-10 08:12:42 by Homer
Q: Why must we install DebugCenter.exe/the ObjAsm32 package?

Also, the error dialog has the window text way higher up than normal (so that you can only see the bottom half of each letter)

I'd gladly try to get DebugCenter, but for some reason I can't connect to your site. :shock:
Posted on 2005-07-10 10:14:23 by SecretSwampert67
I updated the source.

My site is down , sorry.
I am hosted by Ultrano, and his Domain Name seems to have expired... ouch.
I am sorting out some temporary hosting, but I really do require some long term hosting.

The DebugCenter is required to see ANY feedback from the demo in its current state.
It's available as part of the ObjAsm32 package... install that = install DebugCenter.
I had made it available as a separate download, but alas, no dns entry = no fun :(

DebugCenter is a SEPARATE executable - it runs an MDI application which can receive N streams of debug information (N Named Debug ChildWindows).
I have adopted it as my preferred debugging aid, although it is not perfect, its very nice indeed.
Therefore anything I build as a DEBUG version will require this exe to be installed and have been run at least once (to register it).

One reason I like it is because I can change ONE line near the top of my source to disable ALL the debug stuff at build time, without removing it from the source or commenting it out.
IE I can build a NON DEBUG or RELEASE version, which is much smaller due to the debug stuff not being compiled into it at build time :)

Posted on 2005-07-10 10:24:48 by Homer

IE I can build a NON DEBUG or RELEASE version, which is much smaller due to the debug stuff not being compiled into it at build time :)


Would you mind doing that? Size kinda is important on my computer. :sad:

Anyway, I'm not debugging it for you, so I kinda don't need that extra stuff, do I? ;)
Posted on 2005-07-10 10:36:01 by SecretSwampert67
Perhaps you miss the point.
The "debug window" created by DebugCenter is the ONLY visual feedback this app gives.
I use it where some might use a Console as an output window.
I'm afraid that - until I add some gui and / or 3d graphic code, you are stuck with it.

My exe (DEBUG build) is only about 52kb unzipped, and the exe+source zipped to around 31kb.
DebugCenter exe is around 100kb or so, but OA32 package is around 1 and half megs :(

I'm not asking you to "debug" my program - it "debugs itself" pretty much.
All you have to tell me is whether it completes without error or not based on the debug output it produces, and for THAT, you WILL need the DebugCenter app.

Perhaps it's a good excuse to download the OA32 package - perhaps it's a sign to Biterider to make that exe available separately as I did..
Posted on 2005-07-10 10:44:30 by Homer

Perhaps you miss the point.
The "debug window" created by DebugCenter is the ONLY visual feedback this app gives.
I use it where some might use a Console as an output window.
I'm afraid that - until I add some gui and / or 3d graphic code, you are stuck with it.

My exe is only about 52kb unzipped, and the exe+source zipped to around 31kb.
DebugCenter exe is around 100kb or so, but OA32 package is around 1 and half megs :(

I'm not asking you to "debug" my program - it "debugs itself" pretty much.
All you have to tell me is whether it completes without error or not based on the debug output it produces, and for THAT, you WILL need the DebugCenter app.

Perhaps it's a good excuse to download the OA32 package - perhaps it's a sign to Biterider to make that exe available separately as I did..


Ok then, please ignore my moronic posts, I didn't know that DebugCenter was where the output was sent, I just thought it'd be some extra menu that has stuff I have no need of. Oh well, time to download that ObjAsm32 package. :)
Posted on 2005-07-10 10:58:02 by SecretSwampert67
You are not a moron, you are a fool.
A moron is an idiot, they cannot learn from their mistakes, let alone those of others.
Fools can learn, and redeem themselves, via their own mistakes, or those of others !!
Be proud to call yourself a fool, for you are in good company :)

Look mom, no Avatar :(
Posted on 2005-07-10 11:22:27 by Homer
I ran it and it completed successfully (I got debug center earlier with your other project ;) ).


...my avatar's host sux too :P it has something like 40% uptime ["hosting powered by Linux Dedicated Servers"  :lol:]
Posted on 2005-07-10 14:07:19 by ti_mo_n
Hi all!
I added a single entry to the repository section of the ObjAsm32 homepage to download the DebugCenter.exe file.
After it was executed the first time, the app remembers where to start the next time and no additional setup was required.

Regards,

Biterider
Posted on 2005-07-10 15:00:37 by Biterider
Thanks for the feedback, and thanks for putting the DebugCenter up as a separate download :)
How long did it take to generate that world, and on what hardware?

I'll begin throwing some OpenGL code together for a Visualisation Client, and enable code to save generated worlds to datafile.. I may also "oopify" the Generator source at this time.. I left it relatively "vanilla flavoured" in case anyone was interested in how it operates.
It's essentially based on the "cows and fences" algorithm, where each cell begins with all its "fences up", and then a silly cow "knocks down fences" to create the maze.. :)

I already began writing a UDP based gameserver with MM in mind.
My goal is to let the Server determine which Cells are near to you, and send you the encoded Walls bytes for new Cells, and then only when you Move, which means joining Clients never have to download a new Map, and lends itself to a "map exploration" style of gameplay.
It also leaves the Client with so few Walls to render that ClientSide VSD is hardly worth implementing.. meaning the Client can afford to Render everything it "knows about"..

I might just tack the UDPServer code onto the end of the Generator code for now, and let it use file based data later, because I'm impatient :)
Posted on 2005-07-11 00:26:01 by Homer
I've appended my UDPServer code to the 3DMazeGenerator.
I've also written a small UDPClient and a very humble protocol.


GamePacket struct
ProtoHeader dd ?
ClientID dd ?
PacketCMD dw ?
PayloadSize dw ?
GamePacket ends

GAMEHEADER equ "GAME"
CMD_LOGIN equ 0
CMD_LOGOUT equ 1
CMD_READY equ 49153
CMD_BADNAME equ 0BADF00Dh
CMD_BADID equ 0DEADBEEF


The Login Packet expects you to send a ClientID of NULL, and a desired UserName as the Packet Payload. Payload is simply appended to the GamePacket struct, and the PayloadSize field set.
The reply from the Server will dictate what happens next.
CMD_BADNAME indicates that the Name you wanted is already being used.
CMD_BADID indicates that you sent a CMD_LOGIN with a non-null ClientID, which is naughty.
CMD_LOGIN indicates that you are "virtually connected", and here's your new ClientID.

ClientIDs are generated ServerSide, and are random, with the aim being that they cannot be predicted by the Client, but really, they are to identify unique Clients behind NATS etc, since NATS can unpredictably decide to remap a Client's IP and/or Port assignments at any time !!
We must not rely on IP/PORT to identify a Client !!

Once a Client receives a good reply to Login, and has a valid ClientID, the demo sends a CMD_LOGOUT to the Server.
Under UDP, Logging Out is important, because we won't otherwise receive notification of a disconnecting client, since our connection is "virtual"..
When the Server receives a Logout from a Client, it echoes the Logout back to the Client, then removes the Client from its database.
When the Client receives an echo of its CMD_LOGOUT request, it shuts down.
Current support is for 10,000 virtual client connections, totally artificial limit.

Decent day's work, huh?
Posted on 2005-07-11 03:44:22 by Homer
I've added basic OpenGL skeleton code to the UDPClient :D
Update the zip tomorrow ;)
Posted on 2005-07-11 10:53:28 by Homer
Spent a day working on orthographic projections in 3D space.
Implemented a crude ParticleGenerator attached to the MouseCursor - 3D particles are ejected in a mostly upwards direction (a little randomness to the X and Z), and then fall under gravity, until they disappear from the screen, or until they time out.
Perhaps a waste of time, but it served several purposes, as I can now implement HeadUpDisplay and textured menus etc..
No update to the zip today I'm afraid - I want to get a crude game menu in place.
Posted on 2005-07-12 03:18:48 by Homer
Here's the ClientSide with the network code disabled..
A rugged opengl gui with crude game menu in place - heh.
Source included.
You might find the GameMenu oop class quite interesting - it creates a linked node tree comprised of "major and minor nodes", and requires NO SUPPORT OBJECTS.

Have a nice day :)
Attachments:
Posted on 2005-07-13 00:14:51 by Homer
Hi EvilHomer2k
Can you provide some help to get the OpenGL files (download link) and required setup to run your app?

Thanks,

Biterider
Posted on 2005-07-13 01:10:28 by Biterider
Just let me know which files you require.
I've sorted out temporary hosting @ http://stig.servehttp.com/homer
but my hosting problem is not resolved, I still require a more permanent solution :(

As with all my OA32-based projects, any files containing Object Definitions should be placed in OA32's /Code/Objects folder with the usual suspects.

Any other files live with the Asm and Rap files in a "project" folder.

I realized already that I can merge the MenuItem and GameMenu classes into a single class whose Node is multipurpose.. I may do that, but right now, I'm translating a TextureLoader class.

TextureLoader features:

;*? Loads? : BMP, EMF, GIF, ICO, JPG, WMF and TGA? ?
;*? Source : Reads From Disk, Ram, Project Resource or the Internet? ?
;*? Extras : Images Can Be Any Width Or Height
;*? ? ? ? ? ?Low Quality Textures can be created? ?
;*? ? ? ? ? ?Different Filter Level Support (None, Bilinear and Trilinear Mipmapping Support)


I've implemented the Rendering of the Menu Items via orthographically-projected 3D rectangles which are Textured, but currently the image is only able to be loaded from rc, and must be a BMP, and is not loaded with mipmapping support, and looks crap :P

Posted on 2005-07-13 02:30:00 by Homer
Biterider, I'll need a hand implementing this TextureLoader object.
It relies on the IPicture interface to do some stuff, and well, I just wasted almost three hours just trying to get it to build ... anyways, here's the object in question..

Attachments:
Posted on 2005-07-13 14:12:11 by Homer
Nevermind dude, I sorted it out.
The issue related to mixing OA32 objects with COM objects.
Essentially I was trying to OCall COM INTERFACE METHODS which I assume is a no-no.
I further assume that OCall expects the base methods "Done,Startup,ShutDown" to be part of the class whereas COM Classes ALWAYS begin with the IUnknown interface methods..
When I replaced the offending OCalls with ICall, everything seemed to work.. well, it compiles, I haven't implemented live code so I'll hold my breath :P

Basically I tripped myself up on your ComPrimers object(s) also.
I saw standard OA32 objects using standard OCall, and I leapt to the top of the tallest conclusion I could imagine, and as usual, assumption is the mother of all f*ckups..

Well, we live and learn, so they say..

... I can stop holding my breath now :) I found a BUNCH of small bugs and fixed them, then still something was wrong... none of my COM calls were working, so I looked closer... I discovered via Olly that I was executing the wrong code ... so I looked at my Interface Definition again - no problem there, so I messed around for an hour or two more, then I decided to check the IID.
I had obtained the IID for IPicture from the web via Google, and it was wrong - by one digit :|
It LOOKED right unless you examined it carefully.

See what I mean:
<7BF80980-BF32-101A-8BBB-00AA00300CAB> INCORRECT
<7BF80981-BF32-101A-8BBB-00AA00300CAB> CORRECT !!

Crikey, that was hard to spot !!

Posted on 2005-07-13 18:09:18 by Homer
Now that Textures have been wrestled and hogtied, and the Client application is getting up to scratch, it's time to think about how to handle SinglePlayer..
I've decided to go with a Local Server rather than introduce the MazeGen code into the Client, and have the server shelled from the client..
Just a little more spit and polish on the existing client code and it's back to network coding :D
Posted on 2005-07-18 04:09:46 by Homer