Advertisement Jump to content
  • Advertisement

Unwise owl

  • Content Count

  • Joined

  • Last visited

Community Reputation

158 Neutral

About Unwise owl

  • Rank
  1. Unwise owl

    Oddly Shaped 2d Maps

    Quote:nsized tile data 8 bits of repetition That I know, but you're right if there's only one very common value we want to compress (such as for emptiness) n-sized data will do just fine. This is especially true if inside the n-sized tile data a one bit flag is included, which disables the repetition data provided there's no repetition. If that's the case n-size data will at max cause a 1 bit increase per data item (which in pratice is 0 if you don't use that bit for other purposes anyway). Still, having lots of RLE data to step through to access a random tile even with indices for one dimension can be ugly. And I never liked iterating through RLE data overall because drawing algorithms turn less staightforward. (I wrote a fairly simple RLE blitting function with destination and source rectangle clipping and the result looked not-too-nice. Though it depends on the programmer what's perceived difficult, I'm a mere hobbyist. :P)
  2. Unwise owl

    Oddly Shaped 2d Maps

    Or just make a number of rectangular "map regions" with a shared global coordinate system, then offset each coordinate to get the local coordinate in that region. For example, let's say you want a level looking something like this: 11111111111111111 2 2 2333 You can divide it into three rectangular areas and call them 1, 2 and 3. Figure out their relative position to the global coordinate system and add/subtract as necessary to place them correctly when you draw the tiles. I suggest monsters and other non-tile tied entities use the global coordinate system though and only are converted to local scales for collision detection. (By the way you can calculate/store what region(s) (if at border) an entity is in and only test for collision detection in those.) An example (should be abstract enough even if you're not into C++): struct MapRegion { Vector2Df offset; //into global coordinate space Vector2Di size; //width and height in tiles/cells of region, whatever you call them MapCell* tileData; //points to 2D array }; void TranslateToLocal(Vector2Df& position, const MapRegion& region) { position -= region.offset; } void TranslateToGlobal(Vector2Df& position, const MapRegion& region) { position += region.offset; } What I see as a disadvantage of this technique in comparison to RLE compression is region transitions (if you try to group entities by region, what happens when a big entity stands in two or more?). But rendering/collision detection doesn't require much else than iterating through all regions doing what you'd normally do with a single 2D tile array. RLE compression makes finding specific tiles a bit more CPU intensive as you'll have to iterate through your RLE data from whatever indices you keep (maybe rows or columns). It also means you can only represent your tile with a byte (or a short) value describing the type and nothing else. [Edited by - Unwise owl on May 3, 2006 2:44:50 PM]
  3. Unwise owl

    game of life...

    Isn't it possible to keep two exactly the same sized bords in memory, then having two pointers called currentBoard and temporaryBoard respectively. Then you would on update switch them and step over each square in the currentBoard, quering for the corresponding number of neighbours in the temporaryBoard? For any other functions after update it's just to check the currentBoard pointer for the most recent board. This way you avoid two memory copies (if that's an issue, shouldn't be anyhow with small arrays).
  4. Unwise owl

    2D Game Programming

    Quote:Original post by Unknone Don't get me wrong, SDL and Allegro look great. But I don't want to get into the habit of using another 3rd party library or engine because then you can't program properly without them. That's why I don't use graphics engines and anyway, I've already looked at OpenGL. But I need to go to the Win32 API to learn certain things, such as how to load up a bitmap WITHOUT any engines or anything. I will still probably learn SDL and Allegro, but that will be after I have a reasonable to good knowledge of the API. Thnx for the help though. SDL is far from an engine. I'd call it an API and nothing more. In my own game a have several layers of abstraction on top of the SDL layer (eg. I'll never end up calling SDL_X directly but only through my own graphics functions). SDL is very much bare minimum in certain regards, I still had to write my own image format loaders and direction pixel manipulation. And, you don't need to learn the Win32 API straight down; it just isn't necessary because it's an antiquated piece of software soon to be replaced anyhow. The only thing necessary is to get a good grasp of C++ while having fun. Using SDL to program a 2D game can be.
  5. DarkZoulz, you live in Bålsta? Anyway on topic, it depends like it has been said. I usually only have one "main" class per file, but when this class has some small utility classes/structs to support it I often put them into the same header (and .cpp) files.
  6. Unwise owl

    How long did it took you to learn C++?

    I learnt most C++ syntax issues in maybe two years (my excuse is I've been doing this in my spair time and with huge gaps in time when I'm programming and when I'm not). I've been going on for maybe 5 years in total now, but I still suck on the code design aspect. I usually end up having to rewrite code several times because I planned something wrong (or didn't plan it at all). Bottom line, like everyone else here says don't worry if you don't get immediate results. :D
  7. Unwise owl

    Planning Ahead for Multiplayer...

    Quote:Original post by hplus0603 Quote:should the server keep a separate copy of the world separated from the client? In my opinion, it absolutely should with the model that you suggest. It doesn't have to in the Warcraft-3-like setup I previously described, because all clients (including the client that's serving) will have the exact same game state. Okay, then I'll work with some kind of "displayable world" instead that's closer connected to the graphics output (alright since I needed that an inteface to draw world entities in the first place). Quote:You can decide to send object creates, deletes, and occasional updates if that's what you want to do -- it's certainly simpler than getting co-simulation to work right. The main draw-back is that whomever is hosting the server can cheat in ways the other clients can't, because it can send authoritative updates about the entity states. Plus bandwidth -- entity updates will take bandwidth. There won't be all that many entities that need frequent updating so I don't think bandwidth is an issue. Cheating is an issue obviously, but my game is not mainstream and I don't expect people to play with people they don't know. (Instead they can exclude cheaters.)
  8. Unwise owl

    Savegames and My Documents

    I agree with the OP. My argument is simple: A game should keep to the folder I install it in. It should NOT start spreading files in any other directories. I hate not having control of my computer, but instead some not too clever programmers/designers try to impose their organizational ideas upon me. It doesn't make things easier at all, I still have to browse to the damn thing unless I set up a shortcut (it's no excuse that Windows already has set up shortcuts to My Documents).
  9. Unwise owl

    Planning Ahead for Multiplayer...

    Okay, so what I gathered from your posts: Assign each unit/element/piece an identifier: Actually I was already doing this, but it's good to know I'm doing the right thing. Some identifiers are indices into static areas (of course bounds checked), and some refer to dynamic elements such as the armies I was speaking about. Use one protocol: I'll go with TCP then because communication shouldn't have to be very intense due to the game's nature. I won't support server migration: I'll just be convenient and say "set autosaving on the server to the most frequent interval". I'm a bit confused about the client/server concept though (I know what it's defined to be but still). Who's responsible for holding the game world data? Some other storage class (CWorld is what I had until now) with client/server code only interfacing to this data (both sharing in case of singeplayer, else there is just one), or should the server keep a separate copy of the world separated from the client? It's not decided also whether I should make synchronization across multiple machines (although it is what you seem to recommend for an RTS). My counter-reasoning is the client in the case of multiplayer should be able to maintain a reasonable state of the world merely by keeping track of object additions and deletions, and frequent updates of those that are visible. (This game only features a low number of heavily dynamic objects. Most objects just sit in place until you do something to them.)
  10. I've come far enough in my longest running game project ever to start worrying about how to design for multiplayer in advance. I know I want to add some "basic" TCP/IP LAN/Internet server/client capabilities at some point, but I imagine I need to care about how I set up my game world in singleplayer first to allow multiplayer extension later. For the record, I'm doing what could be called an RTS, but it's of a less intense kind. If it will be able to handle up to 3-9 clients connected to one host it will be enough. I'm reading up on TCP/UDP and server/client architecture but I'm nowhere near the end of the beginner phase. Comments would therefore be appreciated regarding my envisioned design: All data specific to gameplay (that is, excluding graphics and user interface components, there is no sound) should be in the "real" form on the host with clients only holding a not-necessarily perfect copy in their own machines. (Hopefully good enough for client orders sent to host to make sense though.) Host would send clients two types of messages: Critical and non-critical. Critical would be sent through TCP and non-critical on UDP. Let's take a practical example: Players move around armies on the strategic map. Once they enter battle players can see the progress of those battles, but not actually influence them other than ordering retreat. Else a battle automaticallly progresses until it's decided. To handle this a TCP message would have to be sent from host to clients that a battle was starting in a specified area, with the specified participants. Once that happens, the battle would progress and information about this progress would be sent through UDP to clients; if a client misses this no big harm done (though he may be annoyed to find his army lost later if lag is bad). The client can on the other hand send a TCP message to the server that he requests to retreat. Once the battle has ended a TCP message with the exact results is sent from server to clients. Since fog of war is commonplace in this game it's perhaps practical to not update hidden armies all that often to any client. As long as the client doesn't need to perform anything else than prediction it should be alright. To make for a transparent switch from singleplayer to multiplayer, I would perhaps need separate sets of functions for all game objects. One for client prediction and commands coming from the user interface, and instead a complete set of functions for the server (which is also what should run in singleplayer mode). These functions would obviously also need to construct relevant messages to be sent to clients in event of multiplayer. Am I too far off or are these decent ideas?
  11. Unwise owl

    Parsing Half Life 2 Map Files

    Quote:Original post by Gaheris The question is stupid, but did you have a look at the Source SDK? I'm not sure if it has any information about the uncompiled map files though. Can't recall that. Probably they don't want people using their Hammer editor for other games since that's what the license says you're not allowed to...
  12. Unwise owl

    Is this legal syntax?

    Just tried something like this after getting curious: int a = 1; int* b = &a; int** c = &&a; int*** d = &&&a; int**** e = &&&&a; Doesn't seem to work... Nor does: int a = 1; int* b = &a; int** c = &(&a); int*** d = &(&(&a)); int**** e = &(&(&(&a))); (Returns same error as if I whitespace the ampersands.) Only int**c = &b; etc. works. Not too surprising as I'd expect an expression such as &a only to generate a value at a temporary address, which in turn you cannot take the address of.
  13. Unwise owl

    Connecting UI Code with Game Code

    Ok, I've decided to throw out the damn CAction base class attempt and do it with mapped function pointers instead like in your example, with or without Boost (as of yet undecided). Having a class for each command just becomes incredibly cumbersome since the action should have complete knowledge of the class it's supposed to modify. Referring to a member function seems like a much more pretty solution.
  14. Unwise owl

    Connecting UI Code with Game Code

    I'll have to look up Boost, I see it frequently around here. Am I correct in that boost::bind is a global function registry? Interesting, but it makes sense because one registry is really only needed...
  15. I've programmed the early stages of a fairly typical tree-based UI for my game. That is, for every parent window there are child windows (that can be derived sub classes for buttons etc.), and when I call render and collision detection functions(click point test) these recursively down the tree (collision detection front to back and rendering back to front). Now, I run into a problem regarding events. I know how to make them, but I don't know what object should be responsible for 1) generating the events, that is, checking for clicks and triggering events, and 2) how to execute certain game code based on what event happened to which window. To solve the former problem I guess I could let the cursor code invoke click events, but that means it will have to know about what part of the UI is active at the moment. (There are two distinct states: "Menu" and "playing".) I have a menu object; I could let it deal with it, but that'd require to have a similar object for the actual game. Perhaps I should consider creating a "CPlaying" or "CGame" object and let it and "CMenu" derive from a base class that has functions that the main loop can call if there was input? To solve problem nr. 2, I was thinking of having a "CAction" class that would be derived for each action that can be trigger by an UI event. There would be some sort of central registry (perhaps one for CMenu for example) where they were linked to an event key. Once an event triggers it would look into this registry and execute a virtual function in the CAction pointed to. I see multiple potential dependency clashes here though. Comments?
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. 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!