Thanks a lot, guys! All of you… Thank you very much! I haven’t got a perfect solution and the animation is very crude. I am still trying to figure it out for myself and fine tune it. Nevertheless, I really appreciate all your help and inputs. If I have any further problems, I shall definitely ask. Thank you. :-)
Working on some music and sound design for two new short films!
Getting out of town for a while sounds nice, but it’s not practical. When you go away you spend more, a lot more, and the wife works.
I despise blender, it’s the user interface. I use max when I have to or tools like Anim8or for quick jobs.
Maybe writing a useful tool might be an option. I find texturing a nightmare. Maybe a tool to help with that.
I’m too much into business, I’d grab some contract ;)
I’m always in spare time mode. For one month, that’s a fairly short game for me, I’m slow and don’t like to be pressured. I’d probably just do some experiments or learn a new tool, or learn more of an existing one like Blender.
If I had a month off I’d probably get out of town for a few days, maybe go to the coast or to a national park or something, and just decompress for awhile.
Then I’d spend the rest of the time working on hobby projects. Not just coding stuff, but I’d do some writing and play some music too. Maybe even catch up on some games that I’ve bought but not actually played.
For me at least, free time is more valuable than some extra spending money. :)
I like the idea.
You should increase the difficulty quickly. I played for about 1 minute and difficulty didn’t change. For such a type of game, I think a beginner should be able to play at max 30 seconds until he dies.
its not that exciting, im just forming pixel coincidences, then spitting them back out, im hoping i get some strange interactive playback, i tell it everything it knows, but what it does with it, could be the funny thing. :)
(HTM, as a form of spacial compression, and frame search engine)
my reason for developing, is im trying to work out a way of storing
a video game in synapse weights.
take the eye, and form coincident pixel groups.
sometimes your not gonna get more than 2, because theres just no
reoccurance, but limiting it to max 2 is wrong also, because later
groups can only use the groups youve made here, and if there was
a 3 coincidence and you didnt get it, the only way you could approximate
it is by collecting the groups of 2 which included it, so theres an extra
pixel taken in for the group, and its not exclusive, what i call it at the moment.
for groups of 2 is ((eyexeyey)(eyexeyey))/2-(eyexeyey), (make it a cube if
you want groups of 3, insane isnt it)
so i dont think wed be collapsing in any hurry, in fact only by losing
virtually all of the whole, could you record any of it… especially since
it would expand the same way each time.
Hawkins may be right, when he shows you the piramid scheme, because for it,
the later levels are all sparsely activated, and are all on or off, nothing
inbetween, and hes implementing temporal compression (pooling) and if it
had all those things, then maybe it could reduce, but against, is the
fact that however many cells in the final region is basicly how many wholes
you have in a purely spacial system with no stochastic nature (mag-tech)
sometimes you wont get a group, but its still important to at least
grab the one, every cell needed to get the reconstruction working, even
if its just one. (but hopefully this doesnt come up that much, because a 1
group, isnt a group, its just a pass up.)
its insane trying to do it, its really hard, trying to use a threshold
activation to do it, is kinda hard, all ive got now is the motion coming
back with lots of false positives, and im not sure whats causing it.
but the frames are storing separately, and are all retrievable, in the mag-tech
i imagine once i get it working, (dynamic alotting of synapse connections
is MANDATORY for a realtime system, being on gpu is no exception) youd be
able to have the eye one side, and motor and functional detections other side,
then it forms coincidences of them, and this i guess will give you the novel
playback of the internals.
if it doesnt do anything interesting, well, you could try adding stochastism
(which is the same as kinda greyscale all the way up, checking frequencies of fires)
and then im stuck, but i cant even get 1 hidden layer working yet, and you
wouldnt want to even attempt another level when there is noise in it, because
it would totally destroy it coming back out if it was enough collections.
so, as i see it, you either probablisticly compress time (hinton) or you record
sequence (hawkins) and whats better???? hmm yeh.
Yes, like Stainless says, you only want to test it once or so, because if you are using text every iteration, that would slow your game way down. It would be better to keep the times in an array and print them out after so long or something. Or even better, just keep a running average of the frame time and print it out when it closes.
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.