What is the reason they made it descend?
Also, a doesn't need to be volatile.
I just fucking FIXED the damn depth testing issue by just moving one line 5 lines down. Just that after messing with matrices and vertices for many hours.
Now i can actually start working on a better map generating, point sprites, collision, lighting, player, GUI, menus and all kinds of cool stuff.
I have now separated the controls from the camera to a player class, took a while to figure out how to send variables to each other.
I've been working on getting fonts to render in an efficient way for days now. Hopefully I won't be sick of C++/OpenGL when I get it to work properly. Looking forward to creating a GUI of some sort afterwards.
Computer Science at school:
5% programming, 95% this:
Phone picture beats screenshot when you need to tell a story.
New version: http://filesmelt.com/dl/Phyzicle3.apk
It should now work for all you guys that reported a black screen/crash/nothing happening!
For the guys with the screen corruption, I'll look into it. I believe it might just be your old device, though
Oh man, seeing this makes me happy
Upgrading the map generator also allowed to have a maximum map size of 342x341, that's one wider that the last one! Though depending on the amount of wall pieces generated, this much can crash because the vertice list getting too big.
Now just to figure out how to flip vertices 180 degrees around to make a roof.
Got back to work on my 3d opencl renderer
Objects are now asynchronously added during the runtime of the program - memory is allocated for the size of all the triangles currently in any object being rendered to the scene, this is all copied onto the graphics card, and then the current engine memory pointer is updated (mutex lock to prevent awful things from happening) to the new memory. The old memory can then be freed asynchronously as well, after this
This essentially means that adding new objects to the scene won't cause any delay whatsoever to the running of the program (though may take several frames for the actual memory itself to be allocated, and the object to be drawn to the screen). Also, because the memory new memory has to be allocated while the old memory is still present, this means that you are wasting a load of memory while transferring the two. I can't think of a way around this though at the moment
Currently though, I am very lazily getting around to implement a system to pass textures to the program. Unfortunately opencl is not a fan of being passed arrays of Image2ds, though perhaps i can pass a 3d texture that is actually the 2d textures on different layers - each layer being an object ID (or a variation of that).
I'll get around to it at some point
Powered by GeeUI™
(Collaborative project with Ziks and Geel9)
Depending on how complex your scenes are (last time you showed it it looked like maybe a cube-room and a couple of spheres) you shouldn't have too much to worry about in scene allocation. If you aren't already just make sure you're storing the minimum amount of information necessary, like how a sphere only needs 4 floats to represent it completely.
My scenes are currently ~200 bytes including my material definitions and I have the same number of primitives as you do, it shouldn't be terribly expensive.
beat detection is worthless in the first place
there is no magical universal tuning for frequency averages that will detect beats on every single last song provided, so there's no point in it for using it for the reasons you'd expect (to do less work)
the problem with beat detection is that to use it for anything useful, you'd need a set of algorithms that could detect beats across multiple different genres and play styles
that's one problem, but you also have the general "how do you define what a beat is?" issue
in the end, beat detection is best used in controlled, tuned cases. but if you're going to do that, you might as well just manually sync whatever your work is to whatever music you're using, because you'll end up actually doing more work tuning your beat detection for more than one song
10% do something with Office 2003, 15% play mari0, 75% sit quietly while secretly planning how to place the cd in my backpack into the cd-tray and reboot using kon-boot with admin privileges so I can fix their antivirus software and set up user rights properly to prevent some asshole from removing my mari0 saves forcing me to beat it each Tuesday.
I ended up accidentally creating the most attractive project of the science fair had to take part in (the robot arm) and got myself a backache and a sore throat trying to explain what the thing did to kids and their parents. The arm wouldn't work 50% of the times, yet the kids were still incredibly amused when I switched to manual control and grabbed pieces of LEGO and let them go in their hands.
The guys showing their projects in the stands next to mine came to me complaining that I were getting all the attention and I replied that I never asked for it and would gladly switch places
The kinds fucking about with the arm were incredibly unnerving though.