One is, of a certainty, astonished at the apparent disinterest of the Internet in trying to understand how that which said Internet so much criticizes does work. Except for Russians, nobody seems to pursue the reverse engineering of UD. This is made all the more uncanny by there being a soon to be published patent: is there some evil design, forcing the mass of mediocre programmers/Carmack worshipers to go the parallel octree raycasting route, impractical except on GPUs? UD is a /, * & float-free serial (non-parallel) volume renderer. Such features should be compelling to reasonable men in view of the fact that one can no longer do inelegant programming on pollutant GPUs in impunity.
A novel volume renderer: Take a pyramid P (quadtree) & a cube C (octree), the latter can be not included in the former. Octasect C, building a front-to-back list of cubes while rejecting those cubes that are disjoint from P, until a subcube C’ is included in P. Descend the quadtree pyramid P until pyramid is black, a leaf or C’ is included in no pyramid quadrant (i.e., C’ spans subpyramids), call the reached pyramid P’. If P’ is not black then if P’ is a leaf, paint the corresponding viewport rectangle with the color of C’ & update the pyramid quadtree to reflect the blackening of P’. Otherwise, for each quadrant P’i of P, if P’i is not black then apply this whole procedure to P’i & C’.
Should be implemented shortly.
Be aware that text output can be incredibly slow.
Using printf for example in visual studio can take up to 120 mS. This seems to be something to do with windows display update code, I’ve never really tried to track it down, but that’s my gut feeling.
One trick you could try is using a floating accumulator. This is very simple and stops frame skip by varying the time each frame is displayed.
sprite.time += time_delta;
Using this system you will never skip frames, but the amount of time any frame of animation is displayed for can vary.
What I am finding is that HTML 5 works…… sometimes.
I found that changing a single line of code and turn an app running perfectly at 60 Hz, to a heap of brown and smelly running at 1 Hz
I am sure that if you use windows 8, internet explorer, and run Microsoft’s web server, everything works.
Change any one of those elements and bad things can happen.
Or maybe Chrome on Ubuntu Linux with Apache
Or IOS and Firefox……
Or a brick, a hand, and a head. Hand applies velocity to brick which applies force to head.
Having written a web browser, I know how hard it is to get this mess of a ‘standard’ to work consistently. Hell there are 20 different ways of doing anything, all of which are supposed to look the same over all browsers. It’s a mess.
I would much prefer a compiled system along the lines of LLVM, compiled byte code, much smaller than text files, easier to parse, et al ad nauseum. However of course in this I am in a minority of one.
Yes, I am std::cout ing the time to see the accumulated time at every iteration. Also there are only four frames, so it is easy to see that the animation is going jittery whenever the accumulated time goes from 2 to 4. It goes from frame 2 to frame 4. Also, this is not happening all the time. Sometimes, it is smooth… Then later, it goes jittery later again. This could also be a CPU issue. I am not sure. I have to check on a different PC. But, thanks for your answer.
i tried to make a mud with ASP and i was dead in all directions. if u want to make a client server game, it ends paying not using ASP to do it, and just use c++. so i wonder if HTML5 is just as horrible to use.
Isn’t this always the way with new web standards? Think how long it took for CSS and the DOM to work consistently across all browsers and platforms…those were bad old days in the late 90s and early 2000s. I don’t know why this seems to be the disease of the web particularly, but it’ll get ironed out.
I’d like to note that following is not my own opinion, but rather opinion of few people I’ve talked with…
HTML5 is mainly an Apple propagated pseudo-standard that doesn’t have solid support across the browsers (there are still issues after few years), yet the companies that created it heavily propagate it. As opposing to Flash (yet this one works as plugin), it works differently across browsers and even in same browser in different operating systems.
My point of view is a bit different, I think that HTML5 is really step in good way, yet I think that whoever stands behind HTML5 standard must be crying now. The standard looks similar to what SQL standards are - different in each implementation, yet never actually implementing standard correctly, nor fully. It’s better than before, but still it is terribly bad.
It’s because the new forums use Markdown. Four spaces indented is what signals code in Markdown. It’s a different syntax than the old BBCode, but it doesn’t take long to learn.
(I don’t know why inline code (text inside backticks) turns red, like this, though.)
You have to use “pre” instead of “code”, with less than/greater than brackets.
instead of [code] you have to put four spaces on the front of each line of code, don’t know why. Maybe the code monkey eats spaces. Makes no sense to me.
I am using chrome (latest version, made sure of that), on windows xp.
None of the code I have tried, or any of the suggestions I have seen anywhere work.
Try giving it an even slower frame rate and see if it changes anything. If you use Reedbeta’s code, you can use any frame rate. If the frame skipping stops with a slower frame rate, then you know that you aren’t getting the times fast enough. If it’s the same no matter how slow the frame rate, then you have a logic error somewhere, and it’s not in Reedbeta’s code, so you may have changed something without knowing it. What I’m wondering, and why I put that pseudo code up, was if you are sure which frame is skipping? Are you positive it’s the third frame? That’s why it would be good to have it actually print the current frame to see what’s what. I really find it hard to believe that glut can’t get the times fast enough, unless you are trying for a really high frame rate or something.
You mentioned frame skipping because of timing. I don’t know what GLUT is doing behind the scenes, but it’s possible its timer resolution might not be good enough to keep up with your frame rate. Each timing function on an operating system has a minimum resolution, and it depends on the hardware as well (what works for you might not for others). Take for instance the WIN32 call timeGetTime(). It has a default 5 millisecond resolution. I think clock() has a 10ms resolution, which is quite bad for low-latency applications like frame rates and realtime sound mixing; however it has its uses and is not as expensive to call compared to higher resolution timers (ie: use the right tool for the job). On the other hand, if you want micro second accuracy you should use QueryPerformanceCounter. In fact, every game engine should have a “StopWatch” class that uses a high resolution timer. Not only can you use it for controlling frame rates, but also in physics and particle simulations as well as measuring runtime performance of your render pipeline, various function calls, etc where timing is important.
var canvas = document.getElementById("MyCanvas");
canvas.width = window.innerWidth
canvas.height = window.innerHeight
BTW, as spolsh mentioned, it would be nice to have a preview/syntax guide for markdown. I too have difficulty getting certain things to work. I use DokuWiki and Confluence all the time and this markdown stuff keeps messing me up :)
<canvas id="c" width="800" height="600" style="border-style:solid;"> </canvas>
Only added style to your first try so you can see the dimensions.
Works for me. tested on chrome and firefox.
btw. How to fix code markup?
I’m sorry, but I didn’t get you. It’s not because of the code tags. I didn’t understand what you did there. Please explain. Thanks.
It should start with zero.Do something like: I can’t get the code tags to work for some reason but:
lastFrame = currentFrame;
currentFrame = //get times and change to int;
if(lastFrame!= currentFrame) //print lastFrame;
haven’t used c++ for a while, but cout lastFrame if it changes.
I AM doing that! Here’s what’s happening… The accumulated time for the, let’s say, 5 frames is coming out as, 1 for first frame, 2 for second frame, 4 for third frame, then 5 for fourth frame, and so on. When it gets to the third frame, it is not 3, but 4. Here is where the frame skipping occurs. Is there something that I can do in this method or use a completely new method that uses elapsed time of the loop to perform the animation? Please help. Thanks.
You have to zero out when you reach the number of frames in your animation. If you have a 5 frame animation that loops, then you have to zero out your accumulated time after you play the 5th frame. Other than that, it should work. Pretty clever idea of Reedbeta, but you could just as well play the animation and zero out the accumulated time after it was greater than the frame rate and cycle the animation.
Available February 6th on the Apple AppStore
Hello again… Would you please elaborate more about how to use the accumulated time. I used it to animate my sprites using the method you described, but at one point the accumulated time gets incremented so much that it causes a skipping of frames. The sprite jumps from frame 1 to frame 3 directly. How would I go about doing the animation smoothly without that happening? If it is any help, I am using glutGet(GLUT_ELAPSED_TIME) to calculate delta time and accumulated time in OpenGL. Please help. Thanks.
It is not that fast actually. Back-face culling should cause much better performance but UD makes do without. A novel thing occurred:
Suppose you are being given a pyramid P & a cube C. Narrow P horizontally & vertically about C with C still in that narrowed P i.e., P’. Let the rectangle R be the intersection between P’ & the view plane. If R not occluded then if R small enough or C is a leaf, output R in the color of C. Otherwise, apply this procedure to P’ & the octants Ci of C, in front-to-back order.
The above admits of a filth-less formulation, meaning free from /, * or those heinous floats. See Q*.c except *M.c in the archive (second link). Am I the only person trying to reverse UD on the whole Internet?
Funnily… That actually happened. The sprite sped up on a higher spec PC which gave a higher frame rate, which is why I opted for variable frame rate where the frame rate is calculated based on delta time. But, since you said both frame rates are independent of each other and fixed frame rate on sprites is unaffected by window frame rate, the accumulator method seems like the ideal method to use in this case. Thanks again, Reedbeta! Your help was once again invaluable to novices like us. Up-repped your post. :-)
Yes, the sprite’s animation will have the same smoothness. Well, if the game runs at a framerate lower than the sprite, then the sprite will be just as jerky as the rest of the game…but that would be a pretty extreme scenario. :)
I’m assuming you don’t want the sprite to speed up just because the game is running at a high fps.
OK, Reedbeta… So, the sprite’s movement is independent of the delta time. Well, not completely independent, but not directly multiplied with the sprite’s frame rate as I thought. I didn’t really find anything on accumulated time in my search, but I completely understood what you explained above. I still have one doubt though. You say the sprite’s frame rate is independent of the game’s frame rate… Does that mean, even if I give a constant frame rate such as 10 fps, my sprite’s animation will have the same smoothness irrespective of whether the game window is running on a low frame rate or a high frame rate? Please just clear this one for me. Thanks.