Hacker News new | past | comments | ask | show | jobs | submit login

You also will want to optimize the approach. For example, do you really need to draw each block as a cube? You could draw slabs of identical blocks as a single cuboid. That will complicate the code, but may allow you to run larger worlds faster. Also, you probably want to be smarter in computing which cubes to draw and what parts of them to draw (in a 'no reflections' world, you can see at most three faces of a cube. There is code for drawing fewer faces on lines 177-185, but that is disabled. If you figure out why, you may be able to improve the code). [My guess would be that the display does not look nice enough if you do. Maybe you will get flicker when looking at blocks near edge conditions (no pun intended)?]

Also, keeping angles in degrees means you have to convert to radians on every iteration. It is easy to get rid of that. That will be a tiny, tiny speed up, but if you want to get top speed, you will eventually have to make many of those.

Almost every such improvement in speed will come at the cost of code readability and maintainability.




So far, all the suggestions seem to be for main.py, not Pyglet.

So is this something that can be "fixed" without diving into Pyglet?


That's because I only looked at main.py.

If you want the utmost speed, you get it where you can get it the easiest. I bet the other code also can be sped up.

I would expect that the major improvements would be in main.py, though. That Pyglet library would have to be really bad to screw up what main.py does.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: