So yeah, this is about annoying things happening in house of weirdos, a result of two completely different and significantly sized families. One side is conservative and specialized, beeing not very open but quite smart and rather tolerant about other people's business if it doesn't get in their way. The other is a huge pack of foolisch every-day people taking everything the medias bombard them with while ignoring everything they can't cope with or comprehend. So it's a clash of different worlds that only matches when it comes to food. Conversely, me as a vegetarian and my sister as vegan will need to sit with all them and have some sort of lunch with them in a very ugly, arch-conservative, traditional German food serving restaurant to celebrate a great-grandma's 90th birthday. Honestly, the German cuisine is a true nightmare to us two. The only option we will have is to eat dull potatos and overcooked broccoli or so. All in a terribly hunter-themed room with trophies hanging all over the place. Combined with this horrible company of stupid TV techno zombies it's a tripple horror show we won't like to endure very long. I mean I'm used to "celebrate" dull birthdays of other relatives like grandparents or so, but my great grandma is actually 90 years old and LOVES this stuff we totally dislike (with the few active brain cells she has left). I won't try to hide my own attitude towards this topic: relative, parent, random people or not - I don't care what sort of relationship people have to me, it's what they are, what they do and what they think. I know that they don't care about vegetarions, I know that they disrespect other livings that are not like them (may they be animals or humans, I don't care anymore). Thus, I don't care either and would prefer to spend my day with actualy freeday and not having to sit there, endure stupidness and also travel the whole day with my parents which are either exactly like the rest or so deviant that it hurts to live with them.
All in all it's a big chunk of frozen shit wrapped in a nazi flag. As if it isn't enough, the process of getting information about whether it's possible to get atleast vegetarian food creates bitter days of discussion with all family members. It's my great-grandma's 90th birthday after all and I can't really say no because it's sort of inappropriate. She can't doesn't really has the power to change what she is now and thus, I don't want to step infront of her and telling that I won't come because I don't like the deer heads there she can't even properly see anymore. Those moments always make me dislike those differences between generations. But totally independent from my great-grandma is the fact that all her offsprings are just completely foolisch and ignorant. I mean I could live with just doing the same and not seeing my family anymore. But this wouldn't make me better, nor would it help making their minds greater than a bean.
One downside of this dynamic concept is that you will only notice size mismatches during execution (though for not fixed size, since this is known). Well, you can't really check before the real data kicks in - invent something that does and you can sell it for big fortune teller money. There's no real function call overhead compared to builtin ones since every parameter passed to an operator will be generate once on the stack and can be left/altered there using the multitarget notation I described in the last post about this topic. If you don't pass any parameter, nothing will be generated. If the function doesn't need to use or check them, nothing will happen. So yeah, it's seems to flow together in a very natural way. Still a lot of stuff to designed and define, but since a lot of basics are already done now (the type system really a major one along with the multitarget idea), everything else should come as well. Surprisingly, indeed. I wonder why.
All this is usually impossible to prevent - each command requires a matching piece of code. That's a lot stuff to check, even for simple alpha blending operations. Anyway, ever thought about splitting the whole formula into several batch operations and doing each block n times in an optimized look? No, because it may require more memory when done naively? Well, that's certainly true, but so many operations are often done on many elements, so it's up to the language designer or scripter to do the loop manually. But still: 5 operations done together 100 times requires 500 command iterations and just a few variables - maybe some stack operations, too, if it's not a register machine or requires additional data. When doing 5 operations each 100 times we get 5 command iterations and 500 operations as optimized as possible (when split and unspecialized of course). We're talking about non-native execution, so it's always better to keep portions optimized in a VM. Even better, this brings the idea of specialized commands for every thing and won't run faster than than in a real program. I need to integrate this concept when implementing my multitarget system for my scripting language.
Pre-post Edit: It works! Totally awesome. I tested this stuff with a simple VM that only knows basic commands on single values as well as on full array blocks and got an execution speed decreased by around 60% on average for simple alpha blending operations on a few million elements. It's the same ratio when using a specialized alpha blending formula, so it's even more worth doing so (in which case it's seems just quarter of the original duration). It's also roughly the same ratio when turning all optimizations on, so yeah: this stuff works very well for VMs. I decided to start designing the VM first and then putting parser and code generation on top of it. This way, I can clearly seperate what's part of syntactic sugar and what not. I'll try to keep the instruction to a the most useful minimum with a possibly human-readable format, so that it's possibly to write it on your own.
Excitement! So, once again, taking your time to think about stuff DOES bring good ideas. This also works very well for my idea multitarget concept as mentioned above, so I can directly generate proper VM instructions by splitting the the formular properly. The optimal case would be a syntax where I can completely drop handmade loops and leave most algorithmic execution time to the VM. Functions will still be sort of slow to optimize, but this makes inlining and code generation even more valuable.
I've been thinking about using it as the target for my recording with Fraps. A 1680x1050 RGBA screen is about 6.7 MByte per screenshot, so I can roughly get 2 frames per second when having an 11 MByte rate. Not really great, but I'm not gonna record in that high resolutions. Also, Fraps probably also does some minor lossless compression on it, so it should be less. Recording at half the size would bring a factor of 4, meaning I can record at 8 frames per second with compression. Taking a real-world example with 4 minutes clocking at 4 GB and 60 FPS at sort of more than semi-half resolution, I'd need 17 MByte per second when recording. The usual size for 1024x768 seems 5 minutes and 4 GByte, so the required rate would clock at around 13.7MB per second at 60 FPS. Hm, recording at half the screen rate should decrease the required rate by half, gonna try this right now...
Anyway, I have a new toy to play and work with. Makes me much happier to finally see me having a proper backup place for stuff like that. Hooray!
Edit: Did a bit of testing and it seems that I can record Nox at 1024x768 and the native 30Hz with no problem. However, I'll still record Teamspeak audio via the internal harddrive to keep the bandwidth low. Very very fine, but increasing the resolution and framerate makes stuff a lot slower. I tried it with Legend of Grimrock at full resolution and 60 Hz. This brought me around 8 frames, so I way roughly right. However, half framerate and screen resolution was perfect for low resolution recording and playing was also absolutely acceptable.
So since I'm against full HD recording for new, ultra-detailed games (you should play the game yourself if the developers can still profit from it), I'm gonna limit myself to older games that don't run at such high resolutions framerates. Or just scale it down. I'm still looking for a new game to let's play after Nox... I'm almost through, the last recordings will be done using the NAS, so I can't run out of harddrive space. And I don't think that I'll exceed the 1 TByte in some time...
I've been tinkering with this for quite a while now and came up with two different models: The first is that all sequences created with "&" that share the same expression level (no brackets seperating them) will be unrolled parallely, "a&b=1" becomes "a=1, b=1" and "a&b = c&d" becomes "a=c, b=d". To expand this, there's a second sequence type build with "|" that behaves the opposite way, working as a multiplier. In combination with brackets, inner brackets will be unrolled first and then unrolled with the outer expression. So "|" is effectly the same as a bracketized "&" and doesn't need to be used if brackets one the same expression level will be solved one after another, generating a large amount of code with just the original expression.
So the second model takes a different yet similar approach by omitting the "|" operator's superfluous function and replacing with the same as "&", but just after "&" has been applied. This generates some interesting behaviour because it gives you the multiplicative behaviour of a pure multi-bracketed "&" expression but combining each singularly unrolled bracket into one that'll be unrolled parallely after "&".
The second approach is superior because it makes additional unrolling possible. I've taken a look at differently formulas and all of them share the same layout as matrix multiplication with a fixed dimension: one completely strechted range on every column and one with a repeated pattern, both alternated as often of the matrix has columns. Think about it: if you take this setup of different operators, you could create any kind of formula extremely quickly. Even more interesting is the idea of taking not only those two operators but a bracket pair that will indicate the resolution level. This way, multiple "loop levels" are possible and you can effectively create several nested loops where each iteration can map to the n-th element of every sequence sharing the same level. Quite abstract, isn't it? Well, I'm very happy about this find as it makes it possible to create an amazing amount of large code cramped into a single function and don't need to waste to any time with loop iteration. Furthermore, this can be linked to an unroller for static content and BAM you got a lot of code merged into a single formula. with no needed iteration or so. It's not exactly about the unrolling thing makes me excited: it's the possibility to remove loop constructs that usually obscure reading. I mean just look at mathematical functions and tell me where the loop iteration is. Well, there's just no except a few sum symbols or so. Stuff can be written as it is and very easy to read. Personally, I found it more easy to understand algorithms and operations by unrolling them manually and then understanding the logic behind. It's harder to understand something the pure algorithm that doesn't have to do anything with the original formula.
So what I'm trying to explain is that I've found something truly awesome that can be used in any VM or assembly based language in equal ways, unrolled or not. So, you see, it pays off to tinker with thinking about this stuff. I'm gonna try some of this stuff with C macros and some ways of iterating variadic macros with known argument count I discovered while working on OOP macros. So this could work very nicely in C as well, though with quite a pervert syntax.
ITK is growing nicely so far. Everything I want to use in some other code that's not too specialized will find a place in ITK. Especially the vector and matrix stuff is quite varied. Though I'm once again convinced that C++ templates are better for anything type-related. However, I'm still not convinced of the whole inlining thing that's imho more important than the generalization interface. After all, function calls in inappropriate places do totally suck. Another reason to code in C and get more creative about how YOU define your algorithms and interfaces instead of complaining about it. No one said that clever C programming is not about puzzling.
Also, I'm going to implement a little OOP macro collection in C and probably add it to ITK because some things sjust don't profit from not choosing classes and virtual tables. I found myself a bit rebellious when my internship interviewer insisted on C not beeing able to do most stuff C++ can do. Well, it's true that a lot of C++ features are not possible in C, but those are rather of syntactic sugar or parser steps like namespacing. There are also some compiler-specific lowlevel optmizations that can't be done in classic C, but those only add efficiency for certain paradigms. The processing will always be the same for both, independent from what you want to do. Anyway, to prove that OOP is possible (with a certain comfort of course), I'll clean up and expand the macros I'm currently playing with and try to add as much as possible. It's won't be as smooth as a builtin syntax of course, but if you really want to utilize it along with normal C code, it's absolutely no problem. The only concern I'm having is that since it's all on a macro base, the used symbols should be as short as possible. Symbols like I, V, CP, P, VV and whatever no are perfect if you no what they are and quick to use. But they're still global, you know. Nothing that can be called clean.
There are also other examples that base on VMs. Thinking about it, Minecraft is a good example hat's possible to "script" with a VM-based setup. Essentially all Java games can be seen as VM-based game footage. Most flexible-to-script engines either utilize their performance very well by not using scripting that often or limit themselves to very basic and fast features. There simply is not much of a different trade-off besides using non-interpreted languages - you have to sacrifice stuff in any way. That said, I'm more a fan of specialized engines that only have the stuff that's really needed for the game. This is also the way I'm thinking of video game creation: choose a set of things your engines should feature and then make a game out of it. Well, I'm also quite conservative about the games I play, so I can't say that this works for those game designers usually doing the work in professional games nowadays. Both extreme approaches have their advantages and I will not try to judge about which is worse and which is better. My personal vision of having a VM-based scripting languages with my very own set of stuff and commands is still what I strive for. Bad side of both approaches is that it takes a shitload of work and thought, so they are both equally demanding on the way...
Sooo, I have mixed feelings about the gameplay, but everything else is just superb. Greatly optimized graphics output (rather easy with those large, repeated grid elements), wonderful animations and a nicely done set of interaction ideas. However, there seems no music but some dungeony growling in the background. The sounds aren't really fitting to what's happening (snails still sound like they hit you and the minotaur's grunt doesn't exactly sound like "I'M HIT"). Would've been nice to have it a bit more fitting. Sure, with no music you have to do your show somehow, but confusing sound choices are rather... Well, let's just say it could've been done better. Though, the legionairy's marching sound is totally terrifying - I bet stuff like that makes it good again.
Anyway, it feels great to play nontheless. I haven't played that many pure dungeon crawlers beside Roguelikes and the last one I finished was Orcs & Elves on the Nintendo DS. Grimrock is a totally different level, way higher and with a lot of polishing done to the graphics. It simply looks correct, that's it. Just like a modern dungeon crawler should look like. There's nothing I can say agains it, the game doesn't give me any possible weak point besides the default party to nitpick about. Then again I'm a very systematic player and can't cope with too mixed strategies. I always preferred to specialize in something if it's not too generic.
That said, everything went awesome and the future's safe for now! Also, I managed to get a nice Let's Play recording routine and video splitting/converting does also work well. The resulting image quality is a bit false but that's just a matter of time to I get it right. Too bad that the Let's Play I started (Nox) had some sort of savegame fault and so I'm not able to continue. This is highly annoying and I wasn't able to find any way to fix. A shame, totally. But this gives me enough room to start something else...
Also, if you havn't noticed, Dark Souls is coming out for PC! Wave yer flags and sharpen you spears: this is definitely omething I'll Let's Play after Legend of Grimrock (which I haven't yet touched in any way but the menu).
All in all I'm wondering how I could speed of my own renderer with this. In whatever way I turn it, it simply doesn't fit and I never get much out of it. Seems that raytracing and destructible terrain is a combination no way near to speed-ups.
Anyway, this should ensure that I can do stuff like with normal operators (though in a somewhat different syntax). Atleast I hope so because I'd like to finally continue the stuff with actual output that's not just made of pure helper functionality. Some further analysation of the current command string render system made me realize how flexible it is. You can feed the system via sorted or unsorted linked lists, via arrays with long, generated commands string or by using a repeat parameter (and thus profit from faster execution because there's just one command to execute). Very nice indeed, but it has way of visibility clipping or scene assembling, which should be done before feeding the renderer. Personally, I prefer to split stuff this way because it's already a bit blown with this command string stuff.
Guess that's another project after I've done the basic 2D/3D stuff for IGE. There surely is still a lot to do but I like to know what stuff should be done next. The more options I have to expand my own tech for future stuff, the better it'll merge with new stuff. Atleast I hope so... Whatever. Creating some sort of scene assembling will be tricky. My understanding of virtual worlds does consist of cubes in cubes or rects in rects. Some sort of boxing is always present but I wonder how visibility detection can properly be done in combination with the graphics card. In any case, I'll atleast have to know what's our frustum in 3D or screen rect in 2D. For a non-perspective, axis-aligned rendering it's in fact trivial - that's not the difficult part. The difficulty is to combine my block arrangement with a possibly arbitrary visibility volume. Hm, in theory I could just interpret the "view volume" as a convex polygon and then apply a specialized rasterization to render determine what screen is visible in the block/box space. That may be a good idea! An octree would be perfect for this: strong, all-same box alignment and a flexible number of resolutions for adding a lot of details. One could even combine animated octrees when using the matrix used for the rotation... Yep, that could work. All I need is "a bit more time"(TM). But I think that's the perfect way of creating levels and 3D scenes for the stuff I do. Guess RPGmaker left it's mark on me with it's tile-based world creation..
What's next is to test it properly, check functionality for 2D, 3D, ND and integrate it into the VM. I'm feeling much better now, this has bugged me for years! Not having own matrix code. After having it infront of me all day, after writing, analysing and optimizing I finally got comftable with it. I even saw the connection that never revealed themselves before. All in all this was a very necessary and worthwhile day.
But still, it's so damn frustrating! For sheer compensation reasons I started playing and recording Nox and got three hours of video and audio material. Lower resolution make recording more easy since Fraps's fps counter is way more visible... Geez, days like these totally suck. I wish there'd be some sort automatic recording start when speaking for the first time. Could make stuff easier to not miss.
I'm beginning to like this for reason. Finally there's a whole room of possibilities that doesn't limit itself like multithreading or so. Plain and simple! Just like I like graphics programming. Ideally, it's also straightforward and logical since it should be quick for the system to execute. Oh boy, I'm looking so damn forward to doing more of this stuff in the future.
I mean just think about: a VM is quite sponsive and a fixed code written with for it is just like a shade executed on graphics cards, just done via the CPU. I'll probably put in all commands and things into it because it simplifies the whole writing of it. I'm already having buffers I can set (which funtion like repeating read-only memory slots) and everything else is just calculating and calling. I might add some more specialized commands for future stuff. Since I can, for example, also add shaders to the pipeline, this might become an interesting way to assemble them. Yeah, wouldn't require any calculation functionality, but for pure cpu calculations, I could also add commands for normalizing sets of vectors and other common minor tasks you'd need to do before starting the renderer and so on. I could also abuse shaders in the pipe line to execute those commands and flush the cycle once to get them back. Mostly interesting indeed if you ask me.
Anyway, I've yet to properly experiment with shaders, their compilation and so on. The biggest concern so far really is the base itself. Calling OpenGL or SDL is just copy and past - API usage after all. Therefore, I'll at first focus on all the basic 2D stuff, experiment with compiled OpenGL display lists and shaders, end the last bits of the matrix code and then implement all desired OpenGL features. If everything plays well, I'll have some nice little graphics engine combining everything in a more comftable and effective way. I'm just wondering whether this will work as good as if with a custom code witout this layer. More direct is usually less latency, so it'd be slower on one site but it does the same as with a typical performance loop, so it's that of a big latency added. Logical thinking tells me that this stuff can't be worse than a custom loop for standar stuff like sending a bunch of polygons and rendering it. It's just looping after all - no need care making the optimal case more optimal as it is.
Also, it's the 1028th post! Though I should've celebrated the 1024th one, I'm gonna sacrifice my last chocolate bar for this unique event.
Low-rez awesomeness was always one of my weak spots.
All in all, stuff will go on and eventually it will make more experience with what I'm doing. Some actual references are always good when applying for jobs and internships. Not those custom engines I write. They are more like what needs to find it's way out of my head. I'm talking about the time you've spend in video game studios and on what professional projects you've worked on.
Oh boy, I can't tell how this makes me feel better just by thinking about it. I know it's rather trivial stuff and completely unrelated to any typical programmer approach (you know, reading and using), but it's just the way how I work and how I can feel comftable with new stuff. That's probably also the reason why I dislike using random libraries that do the stuff I actually want to do myself: I simply haven't yet done it myself! Strange.
Changes to the render system in general:
- split recursive display list rendering into display lists and display items
- each item can contain "command strings" describing it's visual representation
- command strings are binary representations of 2D and 3D drawing operations, position via matrices/vectors and input data
- z sorting will still be kept for display items, so that sorted rendering is still possible
- screens can either be in 3D mode (OpenGL) or 2D (SDL), disabling their respective commands
- for easy rendering, not only graphical primitives will be provided but also sprites, tile maps etc
Command string features:
- 2D and 3D drawing primitives and associated
- position via 2D and 3D matrix manipulation like in OpenGL
- bind float and integer arrays to buffers as command input
- commands will effectively "pop" a fixed number values from the buffer, leaving room to fill or load buffers for a whole series of render commands
Stuff that may interesting for performance:
- ompile command strings as OpenGL display lists that do not change after n iterations (or atleast provide some external function for them)
- try avoiding repeated OpenGL calls by merging sequential or repeated render commands (if possible)
- integrate VBOs and PBOs in some way
So I've decided to build some the same operations for 2D positioning as well. Only difference is that there will be no vertices but drawing position for the drawing commands. I'm feeling a bit strange about randomly writing some stuff that *may* seem useful later and not starting to creating a complete game. All in all I just know that I'm not into doin random stuff or choosing the next best lib that seems available, so I can only sit here and code for what seems the next in having a custom engine for everything.
Those days where you're confronted with your own self-induced stuff though there was the opportunity to work with someone together on a completely different base you've never done and never will is... disgusting. To say the least. I mean everyone is what he is and can what he can and I can create little engine thingies that can be used for greater things, so this is effectively what I do. And writing this right here completely unrelated to anything I've written in the first part of the post may seems like some sort of reflection goin on in a young hardcore C programmer's mind. I never did something different and I don't plan to. The way I see games and programming is so different compared to all other attitudes I've encountered so far that I wonder whether there is actually a place where I feel perfectly fitting.
That's what's driving me nuts right now and for some reason I'd once again want to have some sort isolated time capsule to go through every aspect of game engine programming and realizing them parallely. For maximum self-irony I should start calling myself a "Real Programmer". Just to illustrate the strange, lonely relationship. Hey, that sounds like good catchy phrase...
As a matter of fact, I rather dislike this sort of thinking, but it always comes to my head when talking with fellow students. They see my code and look away. I see their code and want to fix it. The differences in preferred paradigms and positive experiences with it is something that has followed me in the past quite often. Maybe I'm just too arrogant to use the same stuff others do and see them inferior to what's in my head. Or maybe think the same of my stuff.
In any way, there's no real way of not think of possible paradigm collisions. And I bet you do your own part by not appreciating other people's methods that different more or less from your own. Either this or you just know that specific programming is not the only thing in your life and that you identify with different than what you're specialized in.
However, the idea of just having the same command set for 2D and 3D simply pleases my inner n-dimensionalizer. I'm having quite a bunch of interesting ideas to easily build all sorts of nice effects with a few fixed data structs to pass. The more I think about the possibilities, the less I tend to rethink it. That's a good thing because it enables stuff to move forward as well as giving me the instant success I need right now.
Well, I'm just learning right now, so 60% of what I'm saying can be simply false. However, I don't think that I'll need shaders that soon (except when having to use it during my internship or something like that...). All I'm having in mind can be created with simple standard OpenGL stuff, so I'm happy about it! Don't make too big leaps if not required.