Advertisement Jump to content
  • Advertisement

marcusz

Member
  • Content Count

    46
  • Joined

  • Last visited

Community Reputation

148 Neutral

About marcusz

  • Rank
    Member
  1. marcusz

    Old games sounds and SFX

    I know the commodore 64 used the SID-chip. It basically had a few hardware oscillators and a noise generator. Search on the SID chip, download a SID player and some songs. The oscillators at this time were not sine-oscillators but pulse/square and sawtooth. This makes for more complex sounds. Then the program change the oscillator settings all the time to add more complexity to the sound. Sweep the oscillator pitch from max to min for a laser shot etc. I belive this is how most game sounds (and music) was created in the 80:ies. Basically dumbed-down analog synthesizers (Depeche Mode, Human League) etc. Try searching for "analog synthesis" for more references. There are lots of software synthesizers you can use to create WAVE files with sound effects. HTH /Marcus
  2. Anyone else supporting prefabs in your game? How do _you_ do it? /Marcus
  3. I now have prefabs working, but a prefab-instance can only override properties in the top-level game object in the prefab definition... And a prefab instance can't yet add or delete sub-object inside the prefab... Still no one that can point me to some source of inspiration? Or give me some clues? /Marcus
  4. marcusz

    Refactoring/Rewriting

    My experience is that 95% of the time, careful refactoring is the best way to go. 1) Make a design on paper on how you would _like_ the design to be. 2) Select the most troublesome area of your current design and do a number of careful refactoring steps to turn that part into the new design. After each step, everything must still work properly. If it stopped working, fix it _now_. Your program is now much better and still works. If needed, repeat from 2) above. When refactoring you will often add temporary compatibility code. This is the price you pay for the safety of making many small and safe steps of improving the design. It's almost always worth it, though. Joel on Software My 2 cents. /Marcus
  5. Hi! My game uses a scene graph of game objects (GO:s). A level-file contains a list of GO:s that sits in the world. Each GO has a list of sub-GO:s that are positioned relative to their parent GO. This creates a hierarchical scene graph. I use the concept of prefab-definitions files. These files contain a small tree of GO:s that makes up a complex thing. Example prefab definition file: { id = 1, type = "prefab-def", pos = { x = 0, y = 0, z = 0 }, orientation = 0, }, { id = 2, parent = 1, type = "image", bitmap = "spaceship_sheet.png", }, { id = 3, parent = 2, type = "collider", }, { id = 6, parent = 2, type = "image", bitmap = "tail.png", }, { id = 4, parent = 1, type = "speaker", sound = "engine_noise.ogg", loop = true, play = true, }, { id = 5, parent = 4, type = "emitter", particlesPerSecond = 20, startSize = 3, endSize = 30, endOpacity = 0, startColor = { red = 1, green = 0.1, blue = 0.1 }, } Now I can insert many instances of this prefab into all of my level files. Example level file: { id = 1, type = "image", bitmap = "backdrop_stars.png", } { id = 2, type = "prefab-instance", prefab = "ExamplePrefabDef.prefab" pos = { x = 111, y = 222, z = 333 }, } { id = 3, type = "prefab-instance", prefab = "ExamplePrefabDef.prefab" pos = { x = -1000, y = 0, z = 0 }, } As you can see I need to be able to override some of the properties of the prefab definition in each instance. When the level is loaded, each "prefab-instance" is replaced with a copy of the prefab-definition, so each prefab-instance is expanded into a small sub-tree of game objects. The reference to the original prefab definition is kept in each prefab-instance. In many cases a prefab-definition is a complete level (but without the player and enemies). My problems: 1) In my graphical editor, how do I diff the original prefab definition with the in-game prefab instance so I can save-out only the changed properties? I want to be able to later alter the original prefab definition and have it propagate to all instances! 2) How can I override properties of sub-objects of the prefab? 3) How can I delete and insert sub-objects in a prefab instance, and still be able to later on improve the original prefab and have those changes propagate to each prefab instance? Example: reuse a level-environment prefab, but edit the instance to make it look battle-scared, add debris etc. How do the program figure-out the changes? I have looked at plenty of game engines and documents but haven't managed to figure this out. Any ideas? /Marcus
  6. marcusz

    Big levels in a 2D shooter

    Thank you for your replies, both of you! I've got to think more about this. The difficult tradeoff for me is the ease to create contents (tiles are hard since I want shadows to look OK:ish) vs. the VRAM-strain the game puts on Open GL... A new idea I have: 6) Same as 4) but cover the repetition by decorating with lots of tiny objects, like towers and decals. This makes it possible to render the big LEGO-block textures in Cinema 4D - basically big ship-parts, but design them to be less rememberable - basically just shapes. Then draw lots of smaller textures on top to add the detailing. Clever? /Marcus
  7. (I'm using Open GL, but I belive this is a more general problem) Please advice: I have a problem deciding how to do the background levels in my top-down 2D shooter. It's in many ways similar to Uridium and Uridium 2 or even Space Tripper. Here are some images of Uridium 2 on the Amiga that shows what I'm thinking of: http://www.classicgaming.com/shmups/reviews/uridium2/images/snap20.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap22.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap01.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap04.gif http://www.classicgaming.com/shmups/reviews/uridium2/images/snap18.gif I belive Uridium to uses tilemaps... My problem is that I want maybe 20 maps (one for each level) and the maps are very big - some are 2000 * 16000 pixels and I want 1 pixel = 1 texel - no scaling/bluring. I might even store a level as several layers and composite and texture them at startup - all to save disk space. Possible solutions I can think of: 1) One big texture: Uses far too much VRAM. 2000 * 16000 pixel map is 128 MB. I would like to keep a map < 32 MB of VRAM. 2) Proper 3D using Open GL geometry: I don't have the know-how to do this (and make it as detailed with shadows etc.). I prefer to focus on completing the game. 3) Classic tile engine: This makes it so damn fiddly creating the tiles and the maps - especially getting all the overlapping shadows right and all those irritating tiles need where only a little bit needs to be changed to get transients pretty. It would be much faster if I can just render the complete background (or maybe section of it) in Cinema 4D. 4) Pre-rendered LEGO-style objects (basically big sprites) where each goes into a texture in VRAM. They are positioned in the map to together create the big background ships. This is the most practical solution, but I still have the problem of getting them to fit together seamlessly with shadows etc. And it may cause obvious repetition. 5) Split the huge texture into 256*256 textures and expect Open GL to move just a few of them at a time between VRAM and RAM while the player scrolls across the map. Any ideas or recommendations? /Marcus
  8. BTW: lua_gettop() in your example gets the number of arguments on the Lua stack - it doesn't get you the actual argument (message ID). /Marcus
  9. Yes. My PostMessage() has 4 arguments: deliveryTime (milliseconds in world-time) messageType (a string) destinationGO (ID) data (a lua table with additional data, contents depends on the message type) While in C++, a message is stored in a TMessage struct and C++ code can handle these directly. If the message needs to be delivered to a Lua script, I call a function called "OnMessage" in my Lua script, passing the four parameters. HTH /Marcus
  10. marcusz

    Object Management

    Hum-hum... I use this: std::map<TGameObjectID, boost::shared_ptr<CGameObject> > gMyObjectManager; Then I use boost::shared_ptr<CGameObject> or boost::weak_ptr<CGameObject> everywhere to refer to the GO:s, depending on if I need to share the ownership or just track the lifetime of a GO. To lookup a GO from an ID, I use gMyObjectManager.find(someID); I'm not sure if this works across DLL:boundraries, though. /Marcus
  11. marcusz

    Generic Message System.

    Easy speed+memory optimization: use 32-bit ID:s for the message type. The ID:s are actually a hash-value you calculate from a string. This is may be the best of two worlds. unsigned long exampleMessageType = Calc32BitHashFromString("RenderTextureMessageType"); SendMessage(exampleMessageType); /Marcus
  12. This is how my game does this: 1) The C++ engine owns all objects in the game and scene graph, draws everything and runs collisions and rigid bodies. You can attach small "Lua-tag" objects to game objects in the scene graph. One of these Lua scrips can send messages and query some information of game objects and get a small number of notification-messages from the engine. Example messages are OnButton, OnCollision, OnCustomMessage. When your script posts a message you can post with a time-stamp that makes it be delivered in the future. This lets you post a message to your own Lua script to get regular messages. The Lua scripts should _not_ be called every render frame or internal time-step, only when something more rare happens (button presses, collisions). 2) Messages. 3) I use a unique 32-bit ID for every game object so the Lua script (and the messages) can refer refer to game objects in a safe way. You _could_ use lua's lightdata type for sending around pointers in your Lua scripts. Lua cannot access _through_ these pointers, so your code is safe. You need to verify each pointer that the Lua code passes to C++, which makes it just as easy to use the ID method. Remember that the object you refer to might have been deleted when you try to access it. HTH /Marcus
  13. I suggest you have one master position for each object, which positions the object in the world. All other positions are calculated on the fly from the master position, often using the camera object. If you _need_ to store another _copy_ of the position (in physics for example), this is a caching problem. Make sure you always update the master position. /Marcus
  14. Thank you again for your help! It helps a lot to get this confirmed. I 've been think about this problem on and off for a long time, and now I really had to solve it. /Marcus
  • 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!