|
Ugg boots posted:The system works fine for up to around 100 objects on screen, but after I start getting around 150 objects, it slows down quite a bit, which is why I'm wondering what the next logical step would be. I'd like to drop the plane-sweep method and go for something more robust, but I don't know what direction to look at this point. The constraints should remain the same throughout the project, the only thing really changing is the number of objects handled by the detection algorithm. Look into quadtrees. The performance payoff might be a bit iffy for a game with such simple collisions, but in general this is what they're best for. If that's too complex/overkill in your opinion, you can always just do a simple sector system and only compare collisions with objects in the same sector (and have some overlap between sectors). It might seem like that's just as slow because you need to work out which sector they're in, but if you look at the heart of the problem you'll realise there's a combinatorial explosion happening (eg, the number of comparisons is always n!; if you use sectors it could be anywhere between 0 and n! and may not always be less but has a much much better best case) which this can limit.
|
#
¿
Dec 2, 2007 02:51
|
|
|
|
| # ¿ Apr 20, 2024 02:46 |
|
|
Gary the Llama posted:Can someone explain why the NeHe OpenGL tutorials are considered to be crappy? I've stuck with DirectX all this time because I've heard his tutorials are crap, but I'd really like to do cross platform development. So why exactly are his tutorials so bad? A lot of stuff is really poorly explained and there's no logical progression to the tutorials past the first few. There wasn't, for example, a useful tutorial about things like vectors/matrices. Instead there was suddenly some fancy effect that needed an understanding of them and almost no explanation of what was going on that someone who didn't have an understanding of vectors would be able to make sense of. To be honest, past about tutorial 20 it's more like a parade of demos combined with "Look at me! I can prove I wrote it!" than an attempt to teach you what you need to know. Also almost all the tutorials are written in straight C and very poorly organised. You cannot write code like that in a real game - game engines are large things and need reasonably good design. Some of the techniques are also largely obsolete and a lot of important stuff (mostly the stuff that can't be used to make a prettier demo) isn't covered. //Every Single Comment In Every Single Program Is Written Like This For Some Reason, Which As You Can See Is Not Only Unbelievably Obnoxious But Is Also A Neat Hint As To When People Have Copy-Pasted From That Site. I kept an old version of my first serious attempt at writing a game around purely so I can scare people off NeHe tutorials and Sams books for life. I'll have to dig it up and post it sometime, there's comedy gold in there. The Red Book is DEFINITELY worth buying as a reference, but it's a bit too heavy for learning the basics. If you have a half-decent DirectX background you'll find a lot of the concepts map to OpenGL quite easily. Ages ago someone gave me a GameTutorials CD; I skimmed over some of it and it looks a lot better than NeHe's stuff - one of the most complex tutorials has a full BSP renderer, lightmaps, collision detection and all. They cost money though, so I'd wait for someone else to look through it properly before putting down cash. pianoSpleen fucked around with this message at 09:42 on Apr 6, 2008 |
|
#
¿
Apr 6, 2008 09:40
|
|
|
PnP Bios posted:Game Tutorials is crap, at least when they were free it was. It just gives you a folder full of source files, with no clear reading direction, and the 'tutorial' was comments in the source. I would definitely recommend not spending money on them. Ah, okay, fair enough (I kind of assumed I'd just missed the documenting files). Out of curiosity, does anyone have any experience with third-party books on the subject? Like O'Reilly and such.
|
|
#
¿
Apr 7, 2008 03:36
|
|
|
Pfhreak posted:Here's a stumper of a procedural question: You mean like the sky textures in Quake? Where you have a bunch of layers which have parallax? That can be done quite simply by hacking up the relief mapping algorithm to only take as many samples as there are layers. Relief mapping's slowness comes primarily from the number of texture samples used, and I imagine for your application there would only be 3-4 layers needed (thus 3-4 samples). As a result, it'd probably run at an acceptable speed. Then again, you'd probably get a bit more speed by simply drawing one quad per layer in the appropriate position and set a shader to discard any pixel whose depth isn't the correct value for that layer. I'm still not 100% sure that's what you want, though. Can you think of another example?
|
|
#
¿
Sep 11, 2008 02:30
|
|
|
I'd suggest having an Item object (the item instance) with a pointer to an abstract ItemType class. Then you have subclasses of the ItemType based on functionality (weapons, armour etc). IMO this is the optimal solution for most cases - it's only un-flat where there actually is a divergence in functionality (ie - the game actually needs to treat armour differently to weapons). The only place it gets awkward is if there are specific instance traits that only certain ItemTypes can have (for example, a "Condition"/"Durability" trait for only armour). There are a few workarounds but they're all a bit clunky. pianoSpleen fucked around with this message at 16:30 on Sep 20, 2014 |
|
#
¿
Sep 20, 2014 16:27
|
|