next »

[TeaAndBiscuits]

Very productive indeed!

I now have map tools exposed to the Lua console for clearing, saving and loaading. Wrote an in game editor (just for setting map tiles, very simple)

Worked through my fear and pain and got some physics in 
My character now hops round the map with having gravity applied and all that jazz... but more importantly my character NEVER pops or gets stuck in a wall. It took soooo long. Sooooo long... 

-T&B

[Lemming]

I love how the doxygen comments I made generates pretty documentation from mah headers in both html and pdf form.

The pdf gets 75 pages.

And I love this thread, should read through it.

[Kekskiller]

I was able to figure out the problems I had with float values (no, there was no problem, there was just me and a not-working alghorithm) by using a timer-based movement system, again. I can remember that the timer concept already worked before there even was a lightmap system and wasn't happy with it's results (sudden steps and stuff looking wrong but beeing right). The delta/float stuff after it was... just bad. Don't want to use it anymore. Fortunately, small tweaks helped to make the whole a bit smoother and I think it's good for now.

Time for the real physics stuff, yay!

Can't believe how long it took

[Lemming]

I'm happy that I read this thread.

I'm happy that people learn simple data structures, they're useful.

I'm happy that happy programmers seem generally happy.

I'm happy that people mentioned -Wall, good stuff, made me fix some iffyness with my code.

I'm happy that I'm coding our engine thing in C.

I'm happy that... git.

I'm happy that we can squeeze out around 2k shmup bullets in around 100 fps on my Eee 901 in loonix. I'm also using immediate mode since I don't know OpenGL for shit.. :D

I'm happy that the engine turns out okay.

I'm happy that my graphician just jumped out of bed.

I'm happy that my graphician likes the matress I got him.

I'm happy that I jotted down things I'm happy of.

[Hideous]

@lemming Check out Display Lists, they should speed it up: http://www.lighthouse3d.com/opengl/displaylists/source.php3?1

[Lemming]

@lemming Check out Display Lists, they should speed it up: http://www.lighthouse3d.com/opengl/displaylists/source.php3?1

Thanks.

I found a link about them:

http://www.songho.ca/opengl/gl_displaylist.html

The data set I have is quickly changing though, since bullets go in a lot of different directions and each quad doesn't seem like it'd gain anything from being in one. I'm thinking vertex arrays, since every sprite I have is moving quickly. Can I somehow specify that the texture coordinates are the same for each squad?

Thanks again.

[powly]

Instead of display lists, I'd use a Vertex Array or preferably a Vertex Buffer Object. Display lists are great, but calling a list 2000 times is almost as slow as using immediate mode because there are a lot of instructions eating up your bandwidth - especially because bullets are moving, you can only build a display list of a single bullet, not the whole system. With a VA/VBO you can calculate your coordinates on the CPU and send them to the GPU with a single call. VBOs are faster (at least when the object is static, never actually tested this myself with dynamic data but they should still be faster) because they use video memory but they're not supported by very old hardware, if my memory serves they were introduced by the OpenGL ARB in 2003 or something.

EDIT: I don't know a method for telling OpenGL all your quads have the same texture coordinates. But if they have, you don't have to reload any data to your texture coordinate array which ends up being a lot faster, especially with VBOs because they can be stored away in the video memory. With a vertex array you'll still save some wasted processing time and bandwidth when you don't send over the same numbers a couple thousand times.

[increpare]

With a VA/VBO you can calculate your coordinates on the CPU and send them to the GPU with a single call. VBOs are faster (at least when the object is static, never actually tested this myself with dynamic data but they should still be faster)

I think you're unclear here. VBOs are faster than Display Lists for static objects?  AFAIR, they're the same on most cards, and DLs are actually faster on nVidia ones.

[powly]

I think you're unclear here. VBOs are faster than Display Lists for static objects?  AFAIR, they're the same on most cards, and DLs are actually faster on nVidia ones.

Ah, faster than Vertex Arrays is what I meant Don't know if VAs and VBOs are that much different when the object is moving, you'll still have to resend all your data every frame from RAM anyways - I'd still like to think VBOs were faster, otherwise they would be quite meaningless.

[Lemming]

Ah, and also the bullets are (expected) to increase/decrease heavily in amount. So I'm not sure a VBO is worth it, unless it can be dynamically resized, and still kept faster than vertex arrays.

I'd be able to realloc a texture thing for the vertex array, and keeping the largest, and just sending in the length dynamically, even though it's longer in reality.

[Kekskiller]

Real man don't use 3D hardware acceleration

[powly]

VBOs are quite easily resized; every single time you call glBufferData() to update the VBO you tell how many vertices you are sending.

Handling the array holding the vertices might be harder if you'd like to be memory efficient.

@Keks: Hardware acceleration <3 (although some people do magical things without it..)

[Kekskiller]

@Keks: Hardware acceleration <3 (although some people do magical things without it..)

Yeah, that was exactly what I wanted to say.

[v21]

I'm happy because I've found unit tests. Every few minutes, there's more functionality. And you know what's better than that? When new functionality arrives, a number goes up. It's like I get points for writing code. What could be better than that?

[Tycho Brahe]

I just wrote a VERY simple rogue-like engine (albeit without procedural generation) incorporating collision detection and movement using only vb.net and Console.WriteLine()

and I did it in under half an hour...

[Average Software]

I just wrote a VERY simple rouge-like engine (albeit without procedural generation) incorporating collision detection and movement using only vb.net and Console.WriteLine()

and I did it in under half an hour...

I must write a game called Rouge, so that all the people that can't spell "Rogue" will be imitating my game with their "Rouge-likes."

[Tycho Brahe]

oops, I've been doing that all day... sorry

[Christian Knudsen]

I must write a game called Rouge, so that all the people that can't spell "Rogue" will be imitating my game with their "Rouge-likes."

I believe that's why the roguelike POWDER is called what it is (rouge=powder).

[Triplefox]

I am happy that my two DSLs(one for dialogue, one for choreographing enemy movements) work as intended. DSLs will save you from tons of fragile hacks and special cases, and if you set your standards for syntax and theoretical purity low, they are not particularly hard to implement either. I just started using Forth-style stack machines everywhere, compiling them source-to-source as a sequence of function calls - either inline or in an explicit data structure depending on needs. Easy, flexible, debuggable, and you can hack in non-postfix behavior where it's needed.

[increpare]

show us some examples of the second dsl (movement), eh?