Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

266 Neutral

About zdlr

  • Rank
  1. @Matias Goldberg.   About the `static const unsigned int absPlaneMask[4]`. Could you explain how that stops it being reentrant? It is read-only and never modified.    Also, re-entrancy is not sufficient to make something thread-safe. It is possible to be re-entrant and yet not thread safe, and vice-versa.
  2. @hellraizer, thanks for replying. Re references, mean this:   const _Vector3f& aabbCenter = aabbList[iAABB].m_Center; const _Vector3f& aabbSize = aabbList[iAABB].m_Extent;   Which creates constant references to the current AABB's center and extent vectors. References are a C++ construct, not C.
  3. If you're using references, is it still a 'C implementation'?   Could you please choose better variable names than 'd' and 'r'? You then exacerbate the lack of clarity by aliasing d + r to 'd_p_r' and d - r to 'd_m_r' - not forgetting the 'd' field on the _Plane struct.   Would distanceFromCenterToPlaneNormal and distanceFromSizeToAbsolutePlaneNormal not be more explicative? Example code like this benefits hugely from such verbosity.
  4. zdlr

    Game State

    Indeed, think about the 'Pause' state, for example. For rendering, it needs to do whatever the normal in-game state does, but with a big 'PAUSED' text on the middle of the screen It still needs to poll input, but it probably doesn't need to update any game logic (moving actors, etc.) and it should only respond to the UNPAUSE command - FIRE, etc., should be disabled. So, it's a specialization of the normal game state, but by using a CompositeGameState, we can keep the concerns separate while [b]still[/b] promoting reuse. What you end up with, in essence, is a game state graph.
  5. zdlr

    Game State

    "[color=#1C2837][size=2]You are basically trading a messy class for a mess of classes."[/size][/color] [color=#1C2837][size=2] [/size][/color] [color=#1C2837][size=2]True, but each one of those classes should have very directed reason for existing - as well as being small. Far rather more classes than a big ball of mud.[/size][/color] [color=#1C2837][size=2] [/size][/color] [color=#1C2837][size=2]The Brittle Interface problem can be solved by using the Interface Segregation Principle: splitting an otherwise large interface into multiple parts, grouped logically.[/size][/color] [color=#1C2837][size=2] [/size][/color] [color=#1C2837][size=2]Furthermore, you could make a CompositeGameState and have that be the default applied to the Game. Then, the other concerns that you have inside the game (detecting the quit button was pressed, updating the keyboard and pad, plus clearing / flipping the screen) can also be factored out - possibly into a DefaultGameState or something more descriptive.[/size][/color]
  6. Great article. For future reference, it's "without further ado"...
  7. So, after years of starting projects and never getting the time to finish them, I have broken in to the games industry. I'm currently a programmer on the logic team at Beautiful Game Studios / Eidos in London. It combines my two favourite things - football and programming. I dunno how I've managed to get where I am, but I have and it is awesome.
  8. Finally, I've got something to show for my Quake 3 BSP renderer. This is in no way optimised (I'm simply throwing the entire face list at the gfx card), but it is definitely progress. As you can see, although it is textured, the sky box isn't. Also, the gaps are due to not rendering bezier splines yet - I haven't written any tessellation code yet. It looks quite a bit too bright and I'm assuming this is because I'm not using the lightmaps as yet. So, overall, it's rough but it's a decent start. I have a lot of refactoring to do before I start adding more touches but it's going pretty well. Thanks go to paradoxnj and others in the forum who helped me try to figure out some rendering issues that, as ever, turned out to be due to my own stupid idiocy! ZdlR
  9. It's been a slow week for working on my engine. I've loads on at work so I've not managed to do much. I did get my GUI ported to immediate mode (all three widgets) and implemented a trie structure. This is used to store all the configuration settings and allows me to type into the console and get out a list of commands which match the entered prefix. Basically, like the source engine does. Sadly, my trie implementation has a few bugs I need to iron out, but it's almost there. Also, I can load in Q3 BSP files - but there's no scene graph as yet so I can't even render the entire tree without culling.
  10. So, I'm writing a 3D engine for which I hope to make some demos and maybe even a simple game. This is all in the hope that I can score a job in the games industry. Currently, I'm a Business Applications Developer at Kuju Entertainment in Surrey, England. It's a foot in the door and plays up to my previous experience but I'm hoping to make the transition to games development in future. There's a screen shot attached of the current state of my engine, the console doesn't actually have an edit box as yet - I'm porting my GUI to immediate mode this weekend. ZdlR
  11. zdlr


    Shows how good my uni course is then, huh.
  12. zdlr


    True, there's webcolors, too. Apparently, there's some more besides them. I don't think it looks like space invaders without saturating the primary colors in some way [wink]
  13. zdlr


    Hmm, I seem to have imagined that ulong is 128 bit in C#. I'm sure I was looking at something on MSDN that's 128 bit in C#. Anyway, I only used 8 bit places before and that's because I was using a rendermode for everything I was drawing, to test it out. In reality, I think 64 might be enough for most games. --- It was the decimal value type. That's 128 bit. Knew I'd seen it somewhere.
  14. zdlr


    Work has eaten my time this past week. I found some old code from a past (failed, shock horror) game project. It was in C and I thought I could thieve/reuse most of it as a base for Space Invaders (after porting it to C# of course [smile]). I had a look through and I remembered doing something pretty interesting that helped me with a problem that I don't think is mentioned much: Switching what is rendered and what inputs are taken in a game. For example: your main game menu looks entirely different to the 'main' part of your game and it takes different inputs. How do you manage these different situations? What I had done is implement a RenderMode table which linked a number of callbacks to the bits in an __int64. This allowed me to toggle drawing things to the screen by simply bitwise XOR-ing the relevant bit in the current RenderMode. I could then bitwise AND each RenderMode in the lookup table with the current RenderMode and if it came out true I would call the relevant callback which would draw something to the screen. This then extended to my input functions where I would associate each key (mouse or keyboard) with a callback and a RenderMode- ensuring that some keys could be painlessly reused for a menu or in the game proper. I'm currently porting this code over to C# (using ulong so I get the possibility of 128 unique RenderModes) hopefully it will be as much of a success as it was in C. I'll post the C code if anyone wants, I can't be bothered to upload it if it ain't gonna be used [grin]
  15. zdlr

    Describing Heroquest Maps In XML

    <Room Left="21" Top="14" Width="4" Height="4" />
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!