Wasted an entire day wondering why the heck graphics weren't being loaded. I examine RAM, the data is there. I look at the code in a debugger and it's indeed executing in the subroutines it should. I look at the code that sends the commands to the video hardware, pointers are OK, then I step and the loop is running, yet somehow the video hardware is ignoring them... wait a second, did an instruction just get misassembled?
cmp.l a4, a5
cmpm.l (a4)+, (a5)+
Huuuuh not only it got converted to the wrong instruction (CMPM instead of CMPA), where did the assembler get the idea of adding postincrement?
I'm open to hearing about why it's insidious, but have yet to hear a good reason.
That the -> operator is actually a thing and I had to stop and think to figure out how it was supposed to be parsed (because I kept seeing - -> instead of -- >). You definitely don't want to slow down people like that, especially not during crunch period. (and yes, this is all a matter of where whitespace goes, the operation itself is fine)
Also I can attest to the string thing, I swear. I reduced loading times from 4-5 seconds to a fraction of a second just by computing a "quickhash" of each string (just add every character) when the list was first generated, then when it searched for a string it'd compare the quickhash first. Turns out that a lot of filenames differed only in their suffix (e.g. run_1, run_2, run_3, and so on - yeah, talking about animations here). A naïve comparison would have to scan practically the whole strings before failing, but the quickhash made them fail immediately. That the quickhash was stored alongside the pointer (and hence didn't need an extra dereference) probably also helped regarding the cache.
Obviously only useful for things like lists where you compute the quickhash of those strings only once then reuse it over and over, but it's definitely worth it even though it's quite simple to implement.
Why are you pushing the matrix when you aren't using it? (and more importantly, you aren't even calling the matrix functions, not using the parenthesis means they're function pointers instead and on their own they do absolutely nothing)
Anyway, I'd argue that probably the easiest way for you would be to rotate (glRotate3f) the billboard the same angle as the camera, but the other way (i.e. -angle instead of angle). Less headaches to cope with. And if you ever switch to a more modern API than the old OpenGL 1.1, remember you can do whatever is the equivalent there.
Today wondering why a file was 4KB instead of 3KB. Checked the parameters, they were fine. I had just changed the tool not much earlier on the feature that particular file was using so I wondered if I had introduced a bug? But wait, then why the other files relying on that feature aren't broken? Is this one of those subtle bugs?
Then I realized I was looking at the wrong file (ノ_<)
For the record, while immediate mode is indeed slow by today's standards =P I wonder how much performance was lost in OpenGL simply by developers insisting on taking control over everything. To me it was pretty obvious the idea was for the driver to figure out the best way to do things (not as hard as it sounds since the driver is specific to the hardware in question anyway, so it can safely make lots of assumptions), but bad implementations certainly hampered that as well =/ Sucks since the driver is the one that knows best, especially on platforms without fixed hardware specs (PCs, anyone?).
The sad thing is that fx = ix + 0.0f is actually different from fx = ix unless you're using something like -ffast-math (compilers can't optimize floating point operations because that can introduce different rounding errors and hence technically cause the result to be different, which is not allowed by the standard).
Pong is pretty much the most basic beginner game that gets recommended... another venue would be text adventures, though at that point, you are throwing graphics completly out of the window, and your game loop will be quite different (in most cases it will stop waiting for input) than what other games use.
Yeah but it still helps gives you a rough understanding of game states. You just aren't updating it many times per second
Every commercial product I've worked on has gobbled up all the 3rd party code into it's own repo, so it's actually possible to reliably reproduce a bit-exact build of the project as it was at any moment in time.
Or heck, just download the library somewhere (even if just some random directory in a random computer) and work from that (build, make more copies as needed, etc.). In fact I was under the impression this was pretty much the usual way to do things, given how pretty much every library site has some sort of download link. It isn't even high technology, it's what bedroom coders do by necessity.