Cleaning up

Started to sytematically rework my old raytracer code with new ideas, better structuring etc. It's creepy to know that I was (and still am) able to code whatever stuff without putting it into comfortable classes. But since it's now now a REAL lot of time ago I worked on it the last time, noone has to judge over this. I already had good approaches, but I can now see why everything turned out so confusing and overwhelming for me. It lacked compactness and maintainability. A bunch of random and not-so well thought structures. I've had many ideas involving a complete seperation of rendering, physics and everything else. After taking a quick look at the source code, I had a lot of ideas how to optimize it and hopefully put away all the slowlyness it had before. With my n-dimensional vector magic, I can make this one a good-looking and coder-friendly to read alghorithm. For extensibility's sake it will handle contrasts better by using HDR color ranges by default. I won't use anything different from floats cause it's the most convenient format for graphics calculations (and the performance loss isn't a problem, especially cause you gain more free cycles due to fewer required operations compared to normal integers). While this is just a numeric and rather "code reduction"-related area, I'll also need to create some tools for creating game content - most notably map editors for creating test scenes, adding objects and so on. I underestimated the necessity of keeping the map, physics and game logic data distinct and combinable. It's a huge problem for me too keep things apart after creating one part. So I'll seperate everything from the beginning: one data block for colors/graphics, one for physics data and then others for... other stuff, you know! I'll try to keep the game logic itself without special areas triggering events or so, everything should work like an ingame feature to blend smoothly with the idea of having a full destructible map (in theory). It's a) less work for me to sync all others ideas I have in mind with it and b) it gives the player a special degree of freedom to tackle, like in some very open, cutscene-less RPGs or action-adventures. Two design features in one technical! If that's not a useful reduction for hobbyish game designing. Another aspect is to ease the work for multithreading later. If everythings turnin well, it's possible to seperate a set of time-consuming threads for maximum performance and only minor changes between the calculated data from frame to frame. I can't say anything experience-based about it. So it's a start into something new, possibly improving (only used threads for seperated input or so).

Also, the more I expand these n-dimensionale classes, the more classes make no sense anymore and can be replaced by it. It's all a matter of using a versatile base as it seems. Better not focus on "possibly useful one day" but ratheron "what does it make better or comfortable". I forgot about it.

Aimless coding does not make one happy.

No comments: