This is a link to a test project I just made, to see if BYOND could handle a simple rotating wireframe object.
Credit goes to jt_vectors for the actual math behind it.
Basically, there are a set of vectors pointing to the vertices of a cube, and there is a list of which of the vertices have a line through them.
The vertices and line points are shown as 2x2 pixels. There are 8 line points forming the lines between the specified vertices.
On my computer, it runs perfectly fine for a few seconds while the CPU usage builds until it finally freezes and crashes. (See how long your computer will last!)
I'd like to see a similar project that runs faster and longer.
Why does BYOND have to be so slow at computing these basic calculations? Is it really that slow?
From what I could tell, the visual updates of the cube's rotation actually continues longer than when input of the client is successfully received from the server(ran locally of course).
Not sure what this could mean, or if it has anything to do with this.
Why so slow?
ID:132449
 Nov 24 2010, 5:11 pm
|
|
DarkCampainger wrote:
Are you using any icon processes?None in that example, but since then I gave the vertices a unique color, and cached that icon. This is clearly not the issue. Are you reusing the points or recreating them for each frame? What about jt_vectors' objects? The procs in jt_vectors pretty much automatically create new /coordinate or /vector objects in all of its calculations. They should be being garbage collected. Have you tried profiling it?From before Dream Seeker decided to freeze(and yet the cube kept spinning!):
Profile results (average time)What about commenting out all the code relating to the display of the cube, and just running the calculations alone?The calculations have my world.cpu to be around 5-7. To display each point, I add it to the overlays of its loc. (Points are /image objects) What I find interesting though, is that if I just add the point to client.images instead of any overlays, the CPU is reduced a ton and doesn't gradually climb.
Profile results (average time)I still don't know why using overlays would cause the CPU to climb up into Dream Seeker-freezing levels. I still wonder why although Dream Seeker is frozen, the cube still rotates and the screen updates. | |
I've added rotate verbs.
For some reason, using a loop for macros("while key in keys_down", using a macro for the keypress and key+up) causes the CPU to grow while a button is pressed. Removing that and letting BYOND use its usual key+rep macro system makes apparently lets the CPU calm down before repeating. Also, I've added a couple things for visual.. appeal. After a while of rotating and caching certain things, it runs pretty nicely at not-too-big size. Why not?  | |
Runs fine for me, I don't see what the problem is.
| |
Kaiochao wrote:
Why does BYOND have to be so slow at computing these basic calculations? Is it really that slow? It's not so basic. If you try to run any game in Software mode (meaning CPU will handle graphics, and GPU will idle) nearly all games will lag (games which were created in "GPU era"). Back in Counter Strike or Half Life 1 times, GPUs and CPUs were similar in performance, so it hardly made any difference. But something like Warcraft 3 most likely won't run on CPU anymore. | |
Because 3D transforms shouldn't be done by doing a number of seperate floating-point multiplies with a number of throwaway objects created, in a VM-language.
Usually if you want to do this kind of thing you learn matrix maths - see things like http://en.wikipedia.org/wiki/3D_projection for a basic grounding. | |
Are you reusing the points or recreating them for each frame? What about jt_vectors' objects?
Have you tried profiling it?
What about commenting out all the code relating to the display of the cube, and just running the calculations alone?