Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1135 Excellent

About SuperVGA

  • Rank
    Advanced Member

Personal Information

  • Role
    Concept Artist
    Creative Director
    Technical Director
  • Interests
  1. It's tough to make a game engine. Since you're already hell-bent on this, my advice is: Think of one basic game that you'd like to use on the engine, aim for that. Implement the game, then generalize all the components, tear away the game-specific stuff. Use your general components to implement a more complex version of the game, incorporate scripts etc outside the engine itself. Don't focus on the rendering part until last (I personally get distracted and play around with physics and lighting for months, when I should be doing other, more fundamental things)
  2. SuperVGA

    OOP is dead, long live OOP

    Thanks, aside from the organizational advantages I never considered the build-time benefits of this before.
  3. Ah, right. Yeah, I don't think it's something that requires a whole lot of thought either, so it's fair enough. Mostly I was just puzzled as to why the paper didn't reference it.
  4. SuperVGA

    Daily Bonus Logic

    I think it was Need for Speed: World which had me coming back. (And I hated it - really felt addicted and I felt a bit dumb for doing it, even if the rest of the game was good) One would need to do a daily task. I think it mostly involved driving around in an area of the city, to collect crystals floating over the street. Once 25 (?) had been collected, that was it for the day. A little one-time bonus, a "days-in-a-row" sort of bonus was also given. But I was going for this, Audi Quattro I think it was, special car, that required me to do this for 150 days IIRC. On day 80-something, I went to on a long weekend trip and, yeah - bummer. 😕
  5. It's interesting that neither this thread nor the linked paper mentions it: I'm convinced this is just a 3D bresenham implementation. (credit where due) Back in early 2010, I played around with implementing bresenham in a fragment shader working on a volume texture, and it actually did pretty good. It's sort of a nice way to avoid using polygons, if you're into that sort of thing, but it was a little too much branching for my GPU at the time...
  6. SuperVGA

    OOP is dead, long live OOP

    Isn't it still good C++ practice though to keep free functions in a namespace or even within a class, as static functions? I have gotten into the habit of starting to implement every member function as static, and if I discover that using the interface is sufficient, I reevaluate its placement - otherwise I turn it into an ordinary instance member function.
  7. SuperVGA

    God Help Me, I'm Making A Tactical RPG

    Since you've already had some luck with Game Maker, I'd say return to that, see how much you can do. I promise you it's possible to do an isometric map in GM as well - I think your issue in that regard is that you wouldn't know how to work with isometric coordinate systems and tiles - but read an article on it. Check these. Since you're coming from the design angle, then I think the most valuable and important bit you can create now is a design document for your first working prototype. Be concrete about what your game is supposed to do. Describe everything and use it as a bible when working on your project. It's cool to dive in to larger engines and programming languages, but if you can start with *anything* you're comfortable with, I'd say do that. There's some learning associated with making a game either way. And It will be a rocky road too. (Nice portfolio btw - I suppose you're making all the sprites, tiles and visual novel art for your project?)
  8. Do you really need a global, unique id  here ? What's wrong with a 32bit or 64bit application unique id ? It would be a lot faster and would make it even more useful in combination with a hashmap. Looks a little bit like over-engineering to me   Thanks for your input. Yeah, I have been over-engineering. It's probably because I've become so accustomed to these 128bit guids at work that I feel like I should be using those too. But you're absolutely right - less will definitely suffice. I'll moderate this, and overhaul this communicator thing with hashmaps and shorter uids. I only want them to be unique application-wide, after all. 
  9. I currently have  std::map<const guid, CommWrapper >* comm_table;   where guid  struct guid  {   unsigned char d[16];      // Less-comparer for std::map with GUID keys   bool operator<(const guid& rhs) const   {    for(unsigned c = 0; 16 != c; ++c)    {     if(d[c] == rhs.d[c]) {   continue;     }     return d[c] < rhs.d[c];    }    return false;   }   };   But it seems to be way slower than the approach i took before, where i just based the (gu)id on the index the pointer had in a std::vector. for instance truck would be in comm_table[5], and thus its id would be 5.   But I kinda like the idea of using some big, fancy guids. It's just really slow for autonomous inter-instance communication, and I'm wondering if I'm doing it right. Perhaps there's no reason to go this way at all.   Or am i just using a wrong collection?
  10. Wow, the article describes one technique. I wouldn't call it modern, either.   You could explain GPU raycasting, polygon aided raycasting, different approaches to approximate or truncate isosurfaces, so why is MC getting all the love?   And I'd mention metaballs in connection with explaining scalar field polygonization, but perhaps that's just me. Also, here the scalar field is described as "our voxels" - I'd say it's a bit more than that.
  11. SuperVGA

    Geometry Clipmap Question

    I'm back! Thanks Funkymunky, that did in fact help. I ended up understanding it, but before I sat down to rewrite some things, I discovered that I would eventually have to deal with a patented approach, a Geoclipmaps apparently is.   So I went back to sort of a compromise. I do classic LOD chunks now, but baked into a single mesh, where every verex has its fp LOD value set as one of its attributes. The cool thing about this is that i can use euclidean distances rather than manhattan or chessboard distances, and that I get a seamless result, as I lerp the LOD values downward towards the next chunk (which requires it's sample LOD to match its mesh density or be coarser.)   I now have [attachment=19009:standardlod.png]   ... And I'm now at the point where I'm actually considering applying a modulo equal to the highest density -quads, rather than using modulo of a chunk size. (here, the chunk size is constant, only the density changes) This causes obvious but smooth vertex scaling in the distance, which I actually like. Viewing with the wireframe on also makes it more obvious.   I think I've managed to do a fair settlement, but you're welcome to input on the approach, of course! :)
  12. SuperVGA

    Geometry Clipmap Question

    Ah, the only thing I meant by slide was the movement relative to the eye, before the modulo bit resets the positions of the vertices. I see how that was a weird term to use.   I've read so much and re-coded so much of this that I think I need to take a break. All this talk about grids is weird, when they are not really complete. I somehow fail to comprehend why I should use an odd number of cells in the "grids". Also, is it supposed to be the innermost grid that's 2^n -1, or the surrounding ones?   Anyways, thanks for trying to help out. I thought I got it, but it appears that I didn't really do it how it's supposed to be done. And now I'm sorta stubborn to learn the "right" way. :)
  13. SuperVGA

    Geometry Clipmap Question

    Hi Funkymunky! Thanks for responding. Yes - those are the ones I'm talking about. The way you do it, do these triangles that connect the two LOD levels maintain size, and therefore overlap either the inner LOD area, or the outer one, as the camera pans across the landscape?   Because with how I do it, letting the innermost slide to a max of 0.25 (as the innermost quads are 0.25 in width and height), and letting the next layers slide by 0.5, 1.0 etc in each direction, there is at most a gap or an overlap between two LOD levels of the inner quad size. And this means that the gaps are often narrower. But I see your point. Just as how I've mapped it down, there's still something I need to figure out.... Huh. - Could it be that I'm fitting the inner part of the coarser LOD to the finer? This means having fewer vertices to move around than if I used the outermost triangles of the finer LOD level...   I keep my LOD value for the vertices in the texcoords, but it seems we do just about the same thing with regards to picking the applicable level.
  14. Hi Guys! Been a while! My project sees constant changes, and it really helps that I learned to stick to stuff. That said, I often see myself rewriting a module or replacing it with others. Feels clean.   I've tried to grasp the principle of Geoclipmapping. Following various articles, but mostly the one from GPU gems 2 (see, I even used the colours :P) I get that all the vertices should move relative to the camera movement, and thus represent static points in the world. While I'm mostly successful at this, the "rings" that represent the overlap between the detail levels cause me some headaches. (They're the ones on the picture which fades to a darker colour on the inside) [attachment=18917:geoclipmaps.png]   I've done it so that these rings will snap to the same points where the outer vertices on the ring within are. That means that these in-between rings scale a bit, and that the quads in the corners have issues snapping to the inside.   The individual rings are each offset with eye.xy modulo size (where size is the size of an individual quad in that ring) - when I look at these isolated, they move seamlessly, so I think I got those right. But I can't wrap my head around how the ones on the inside can stay without being distorted a bit. And how to do the corners at all.   Any feedback or hints highly appreciated! :D Have a good weekend,
  15. SuperVGA

    How to profile SIMD

      Hi Rob,   Why do you recommend passing vectors by value rather than reference? I've made it a habit to use const ref parameters wherever possible, and wherever ref makes sense compared to the size of the type (I wouldn't pass a char by reference)
  • 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!