Those who visit this website regularly have surely taken notice of the percentage of the converted levels for Quadrax Definitive jumping to 100% rather quickly. This means that all 500 levels from all the Quadrax games have been converted! How is that possible!? It is mainly because I have reevaluated creating the conversion program of the level data files from the ground up. With Quadrax III and IV it was rather simple, as these titles have little active elements, but with Quadrax V I started hitting issues regarding how to correctly convert new functionalities like fragile stones, transporters, large moving walls etc. knowing that future Quadrax titles would have more and more of these active elements with each successive title. Therefore, I decided on a different approach - instead of adding new features to the conversion program each time I would need new elements (just like the original Quadrax titltes and their active elements developed), I decided to create a converter for Quadrax VIII directly. My Quadrax games, you see, are 100% backwards compatible, and so I could make sure that me making a well-written data converter from QVIII to QD would guarantee it working on any other older Quadrax title.

And that's exactly what happened. After finish the level conversion from QIV, I expanded the converter with the abilitity to convert QVIII levels, including all its objects. And as soon as that was done, all it took was to run the converter on the older titles, like Quadrax VII, VI and V. And surprisingly enough, all the data was indeed correctly converted to the QN/QD engine.

Nonetheless, having a converted level for the QD engine does not guarantee its playability in QD. Despite all said above, I still have to play each level in its original respective Quadrax and then in the QD engine. Starting from Quadrax V, this is usually followed by a complicated procedure of tweaking levels such that these levels work in the QD engine, just like was originally intended.

Quadrax Definitive should more or less be my Magnum opus. This is why I strive to properly and carefully each and every level from the original games, and if needed, fix some errors that surfaced all those years back. Over 10% of the levels in QD are brand new levels (replaced levels are ones that had bad references from the player base or were repeating - "corrected" version of those levels sometimes appeared in next Quadrax games, replacing the "imperfect" levels of the previous titles in an effort to fix them). Still, over 20% of the levels (i.e., each fifth level!) have been fixed in QD compared to their original release - if it was possible, opportunities for unplanned solutions were eliminated. (Well, I hope so ...)

As has been said, the levels have been converted, but they still need to be reworked into a playable form (or fixed) and then create their new graphical look. This takes on average about 3 days for each level. So, with the 360 levels remaining (QV - QVIII) this may take about 3 years. And that is considering I would not go on any vacation... Ooof...

As everyone has surely noticed, the episode 5 is really dark - and now I mean the graphics side. Which is why it might be a relief to hear that unlike the previous episode with dark decks enlightened merely by jellyfish, in the next episode we shall set off to Nevada desert. What might scare the players, however, is that day and night will be alternating once again.

But before you start rolling your eyes, it is needed to say that I have learned my lesson from the critical opinions that went with the episode 1, and unlike that, it uses entirely different parameters. Nights are shorter than in the first episode, while days are significantly longer. Particularly, I revamped the shader parameters, so even at midnight the level is bright enough with sufficient clarity - which you can see in the following screenshot and compare it to the one in the gallery taken at noon. Moreover, there are no downpours or thunderstorms, so there will no longer be the infamous "midnight storm" combination from the episode 1 ... ;-)

As thorough players might have noticed, I have published a screenshot from the Titanic episode. It's quite obvious now that the majority of the episode will take place inside the shipwreck.

Unfortunately, despite Titanic being quite famous, a number of historical photos that would capture its machinery or under deck is absolutely measly. For instance, there is almost no picture of the original steam engines that propelled the ship. The only available (and usefull) one is from the construction hall where the steam engines were built, and even that is covered with scaffolding from all the sides, and on top of that all, it wasn't taken from the best angle possible:

Either way, since I wanted to have as many authentic elements - with regard to graphics, that is - and since there really was no better picture than that, I couldn't do anything but to actually start retouching this photo.

So, I removed the scaffolding and drew the rest as I considered the best so that it would resemble the original construction as close as possible. I also altered the perspective so that the final graphical object could be used as a complement element in the level "Engine Room", where these two steam engines are placed the way they would be placed in the actual Titanic - which you can see in the episode screenshot, but also here, in the developer's diary where I'll show you the steam engine of the Titanic from a lateral view after all the alterations and tweaks that took me about 2 days:

And so, this is how I've been "playing" with every single graphical element in the episode 5. It could be said that with regard to machinery gear (or should I say the background graphical elements in the episode) everything will be based on reality, and all the gear will be exactly replicated from the original Titanic in the state in which it went for its first (and last) voyage in 1912.

Since episode 3 is practically finished (now I’m just waiting until it’s tested, and until the story is written, translated along with the clues + corrections), I started working on episode 4.

The undersea world is quite a challenge. This time I really wanted to make it look as if it was “under water”. So, not like in QVI, where there was an also an undersea episode in Atlantis, but it didn’t really look like under water. With that all in my mind, I decided to write a special shader for episode 4 that not only decreases the contrast, and gives the picture a bluish feel, but most importantly of all it gives an effect of “water waving”. Debugging this kind of wave shader took me quite a long time, to make the result not too disturbing (some versions were even sickening!) but still noticeable. I’ll see what the main tester Nightmare will say once if he’s done testing episode 3 which will take a while.

But even after finishing the described shader, the environment looked still somewhat “empty”. The already mentioned contrast was one of the things to blame – it looks more real, but less lively. The whole environment kind of lacked some elements that could “liven it up”. It was clear to me what the undersea world needed – fish! Although, had I known how difficult it could get, I probably would’ve given up on it from the beginning. ;-)

First attempts with the static shader were absolutely disastrous. After several attempts, it was clear to me that fish MUST be completely animated, so that they wouldn’t look like dead plastic models. And since I decided that one of the fish must be the icon of undersea danger - Carcharodon carcharias – or shall we say, great white shark, that made for a huge backlog once again. To find quality scenes usable for creating an animation for QN was simply impossible. So, I decided to do it the most difficult way possible – by creating a 3D model and its animating.

Had I created the mentioned 3D model myself, you probably wouldn’t have ever got to see episode 4. Fortunately, there are plenty of 3D models available for free, so after a few moments, I managed to find a rather well-formed model and import it to Blender:

That, of course, was the simplest part of the process. The crucial thing was to get the 3D model moving. I’m not going to describe my week slog as to how to learn in Blender to get the 3D model moving using the animation scheme. Simple as it might seem, I quickly realized that shark’s motion is not that simple after all. My first attempts looked like the shark was suffering from palsy, and even those who haven’t seen the film Jaws would’ve questioned its legitimacy. ;-)

During next and next days, I spent watching videos on YouTube and studying the anatomy of a fish body and shark movements, I finally managed to end up with a somewhat feasible result. It definitely is not as flawless, but I probably won’t do it any better – they probably wouldn’t hire me as an animator in Pixar for films like Finding Nemo. ;-) You can see the screenshot from when I was working on the animation of the 3D model below:

After finishing the animation, all I needed to do was choose appropriate lighting. Just like all the animations since Quadrax X and above, to create a movement from left to right I used two sets of different animations instead of just creating their mirrored counterparts. Then I just rendered the final animation sprites, I merged them to grouped bitmaps and imported to the QN engine. There I finally created the algorithms for vertical and horizontal movements of the sprites (which are, basically, slightly modified sinusoids) and voila! Finally, something moved below the surface!

It was a bit of slog, though, to create a correct diameter. Since for some objects (mainly small ones) a realistic diameter simply cannot be used, and some objects have to be enlarged, here I came across the opposite problem. In a truly majestic length (i.e. corresponding to 6m) the bitmaps of all 240 frames per animation (120 frames for left/right model) took immensely much space in the video memory. After lessening its size by about a third (i.e. to about 4m of diameter length) everything was fine with regard to memory consumption, but the shark was just too tiny, and its dignity and magnificence were long gone. With my teeth gnashing, I lowered the frame rate of shark animation from 30 fps to 15 fps. This saved half of the animation sprites, and therefore half of the video memory capture for this specific animation. It is true that 15 fps is not sufficient and the resultant movement may be jerky at times, but that’s the sacrifice I had to make in order to make the game work on older machines.

Of course, sea fauna cannot consist of sharks only – the opposite is true, these predator of the sea world are quite rare (and that applies to what is pictured in the game). Fortunately, with the knowledge I’d gained when animating the shark, it wasn’t too much trouble for me to create several other species of fish. Although, here I faced another problem – in order QN to remain with regard to graphics memory consumption in norm, I had to limit the number of their species, as each fish has 60 animating sprites and the corresponding bitmap does take some space in the video memory. Nonetheless, even with a few fish the level environment is now a lot livelier, as “something keeps moving in there”. ;-) So, I hope that the environment won’t be as mundane for players as it would be without the sea life.

And for the end, I have as a bonus a rendered picture of that shark. Needless to say, you won’t see it in that perspective in Quadrax. In the game it is visible from a profile view swimming from left to right or vice-versa, and of course in a smaller diameter.

When searching for music for episode 3 I came up with an interesting idea. Why not give episode 3 a slight feel of nostalgia and use for the beginning of the music mix the track from icy levels from the original Quadrax 1?

The idea is simple, its realization not as much. The technical quality of the original music (or its samples) for icy levels from Q1 is similar to the time when it was released - 1996. Nowadays, very few would actually try using low-quality 8-bit samples, so I decided to completely remaster the track. In the program OpenMPT I extracted the respective samples and replaced them with their 16-bit counterparts. I tried to find as similar musical instruments as possible to make the sound of the new samples as close as possible to the original. I often couldn't avoid making great overhauls in the new samples or their creating on a synthesizer. So it took several days to completely replace the old samples (and slightly finalize the sound of the new ones).

But the result is, in my opinion, completely worth it, nevertheless thanks to the 16-bit samples the sound is much clearer and has a significantly larger scope of heights and depths. I didn't mess with the score, so the song consists of four tracks and it will the old-timers time to remember the experiences with the first Quadrax. ;-)

The poll on the forum has inspired me, so when I started working on the third episode, it had already been decided about this environment - it will be icy caverns. And that's mainly because it had never appeared before in any of my Quadraxes. Sure, there had been some winter-themed levels, but external ones only. However, episode 3 will be closer to the original rendition of these levels in Quadrax 1, and they will be closed, "indoor" levels in caverns.

In order to create the visual sides of these levels, I launched DOSBox and played all icy levels in the original Quadrax 1 to get used to their atmosphere and try to create similar levels. I also made a screenshots from these levels to be able to compare their color palettes and use it to create my own levels. You can see how I've been doing so far from the design of the first level for episode 3 and also compare it with one of the level from the original Quadrax 1:

Episode 3 - level design concept



Level from Quadrax 1

It's only three weeks before the game is released. That's why I was shocked when I found out that two variables in game code, storing some users level time in milliseconds, are defined as only 32-bit! Programmers may already suspect where the wind is blowing from. For the rest of you, I will explain that. 32-bit variable can gain a positive integer scope of values 0 - 4294967295. So, the maximum value such a variable can have is those 4294967295 milliseconds. That makes about 50 days. So, if someone solved one level for more than 50 days, that value would "overflow" and it would be counting from zero again!

So what I should do now? Remaking and dismantling the whole structure of user data couldn't be taken into consideration so shortly before the game release. Fortunately, I'd created one "spare" 32-bit variable which hadn't been used before. So I decided to use it to expand the scope of the two time 32-bit values the way I would "halve" that value and add each of those halves to those two 32-bit variables. Therefore, at both the variables I get 48-bit scope which is IMHO enough, as the maximum value of a 48-bit variable is 281474976710655. In milliseconds, this value represents about 8925 years. Certainly, it wouldn't prevent overflowing from happening and counting from zero again. But only if someone played a single level for almost 9 millennia ;-). And I don't assume that ;-)

Someone might think of how it is with showing the overall time you've spent in the game which is also measured in miliseconds, as such a value can go beyond 50 days very easily. Here I need to say that this works without problems, since from the ages of the first Quadraxes counting this, I always defined these summary time variables as 64-bit and an error (overflow) would occur only if you played Quadrax for more than approximately 585 million years... ;-)

So, I was thinking how I could simplify the publication of the best results for players, and its result was clear - the easiest and the simplest solution would be if the players could send the results themselves! So I sat on the computer, dusted off my PHP knowledge, and created a form and processing script that can upload to the web's database the current players' results!

On the page of the records in the upper right-hand corner is now a button Send user's data. Clicking it will get you to the form for sending the processed data file (it's the file you create using the program QN userfiles packer what is a counterpart of the one that was in QX and also has the exactly same controls). However, you have to perform the first sending to my e-mail address, just like at Quadrax X. Unlike in Quadrax X, though, you need to send that file to me only once. I will immediately create you an account, generate a password, and I'll send you that password back. The password will then be able to be used for sending data yourself! The procedure is simple and always the same:

• Using the files QN userfiles packer, you create a current file of your user data, and save it to your drive.
• Then you follow the steps on the page of the form for sending data, where in the step 2 you need to choose the file you've just created.

It is truly simple. But in your first e-mail, where you will be sending the file of user's data, don't forget to write under what nickname you'd like to be mentioned in the chart, and also the name of your account in the game, so that I will be able to put everything to the database! If you are not an old timer who also attended the rant in Quadrax X, also tell me your nationality and gender, if you want to have this data stated in the chart.

Note for the players from abroad - if, during your attempt, a webpage shows up that access has been forbidden, it's because your IP address is blocked by the webhosting provider (webzdarma). Unfortunately, I can't do anything about this. In that case, send me your files created in QN userfiles packer to my mail, just like at QX. I will carry out the upload myself, afterwards.

I couldn't bear it any more. I was fiddling with pixel shaders for so long that I have decided I will remake the whole Quadrax Neverending rendering engine for its usage. And what does this mean in actual fact? It means that the day cycle (switching of the day and night like I mentioned in the post from June 26, 2016) will make its appearance in QN!

Thus, the day and night will be cyclically changing in the game including completely fluent transitions (darkening/lightening). I set the duration of one cycle (i.e. imaginary 24 hours in the game), after a thorough consultation with the tester, to about 30 minutes of real time. This means that if you play one level for thirty minutes, all day cycles will alternate. A shorter cycle would be distracting, a longer one on the other hand would be dull. I also need to highlight that the tester (Nightmare) himself has already played many hours in the game and he rates this cycle as an optimal one. But the players don't need to worry that they would spend a half of this cycle in the dark "night mode". That's because the duration of the day is a lot longer than the duration of the night! The full sunny day takes up 65% of the entire cycle, darkening and dawning will take up 25%, therefore there's only 10% left for the night which means that the true length of the night cycle is mere 3 minutes of the real time. Once again, I need to say that these values have been chosen and tuned after a long-term testing. For those who keep waiting restlessly for QN may be pleased to hear that the implementation of this feature will not delay the game release, as I've added this system directly to the game while testing the current episode 1.

However, this is not all! Since you really can do a bunch of cool stuff with pixel shaders I have added one more thing that had existed in QVIII already, although it hadn't been used in QX. Those who have finished both the games, probably suspect the thing. And if they suspect it's "weather", they are right! In the episode 1 of QN you will be able to enjoy sunny, cloudy or rainy days. Certainly in a reasonable measurement! I doubt that there is anyone who loves too rainy days, so there's a ratio of nice/bad weather that is set at about 6/1 (it rains mostly one day in a week). And why am I talking about weather (what is rather a minor effect) when referring to weather? Because it's the shaders that allow a wonderful sunny day to shift fluently to dreary showers or cloudy storms and vice versa. The effects of weather will therefore become really groovy and will come closer to the realistic image. On top of that all, there are other miscellaneous effects regarding the weather and the daytime (or the mutual combination of both) such as an occasional rainbow after rain, sun rays at dawning etc, etc.

Players who don't own the newest computer may have thought of something similar: "Well, that's all nice, shifting of the day/night, weather, effects but how will my old computer cope with it?" I'm not going to beat about the bush or deceive, you won't play QN on the computers that rather belong to the museum of information technologies than on the desk. But honestly - we have the second decade of the twenty-first century. So if someone uses a computer from the last century, they mustn't be mad at me for the fact that QN won't run on these archaeological (although precious) excavations. On the other hand, the pixel shaders 2.0 used in the game can be coped with easily by a ten-year-old graphics card and the system with Windows XP and DirectX 9.0c. So, it isn't that "horrible" with those hardware requirements.

Small mathematical section for the Xonix game I published a few days ago. From the mathematical point of view, this game is really interesting. I even dare to say that no one in the world can play the same game like anyone else. Let's invite for help the already mentioned mathematics and also statistics: The amount of possible situations in which level 1 can start is exactly 7 792 800. (487 050 possible xy coordinates of the dot * 4 possible initial directions of the dot movement * 4 possible initial directions of the black square movement). Once a player joins the game, the amount of other different situations on the screen is basically infinite. (It's such a big number that it doesn't have any sense.) At level 2 the amount of possible starting positions is 15 181 932 960 000 - yes, over fifty trillion. And level 3 (with 3 dots only) can start in 29 577 441 792 672 000 000 possible situations!

You certainly understand that it is not necessary at other levels to mention the precise numbers (e.g. in level 10 it's about 3.15061e+63 starting situations, i.e. a number containing 64 numerals!) From the statistic point of view it is therefore impossible that two games even at one level could be the same. Certainly, connoisseurs may object that the generator of random numbers in PC is not like a real generator of random numbers at all. Even so, it's statistically clear that no one will ever play the same level as anyone else or the player himself.

Another interesting thing is about the movements of dots. Regarding the fact they move in a finite aggregate of points exactly diagonally, each movement of the dot in no matter how complex bordered area is finite. And it's either cyclically or "pendulously". (It's pendulously in case that at a specific moment the dot rebounds to the exactly opposite direction of its previous movement - thus, at the precise collision to a convex or concave corner). Occasionally, this movement is observable by a naked eye too at the movements in small and relatively little areas (square or rectangular).

And I could be going on about this topic for long. However, I won't keep tiring the players with other mathematical analyses. I think the facts mentioned will do for now... ;-)

Last week I played a little bit with Pixel shaders and the idea of its possible implementation to QN. It would allow very interesting things, the most interesting of which would be the option to dynamically change daytime in external locations. I carried out several tests which exceeded my expectations with regard to the visual impression. In the following pictures you can see changes in the background in different times of the day (certainly, in the game the screen would change gradually and inconspicuously):

In the day



The evening/dawn



At night

Certainly, the entire level would change and not only its background - so in the day it would look the same as the screenshot in the gallery and at night it would look respectively like the episode 3 in QX.

* - See July 26, 2016

I’m a little bit worried that the developer’s diary on this website will be more succinct. But there’s not much to write about, right? The engine for QN is apart from few animations and enhancements taken from QX, the graphics quality of each level depends mainly upon the “drawing” of each level in an external graphic editor, etc. So here we’ll talk about the most significant change which is dynamic loading of textures and animations.

So, what exactly is it and how does it work? In Quadrax X all needed textures, animations etc. were loaded to the memory exactly when the game was launched. As it was 200MB of graphics data, the loading lasted a few seconds. (This is also the answer for those who think that the introductory screen “Loading” with a percentage indicator is just a graphics decoration – it isn’t. ;-)) However, after the game was launched, all graphics and animations of all levels were easy to load, therefore launch of each level was rather simple and the engine didn’t have to take care of anything, since all needed textures had been already loaded in the memory.

In Quadrax Neverending, though, I had to choose a different strategy. Regarding the fact that the amount of levels and episodes is virtually limitless, I couldn’t choose the same principle as in QX as it would cause by adding more and more episodes and more and more textures the continuous and unacceptable increase in the memory requirements of the game. So Quadrax Neverending works differently with regard to this. During its launch it only loads the rudimentary graphics – game menu etc. Thus, QN launch is therefore tremendously swift (approximately 4x faster than at QX). However, as everyone already suspects, if time is saved at some point, it must be added somewhere else – and this time is added during launch of a new level during which the game engine “checks” what is used within the level, and will only load these textures and animations that are used in the respective level. If there is some graphics data in the memory from the level that was played before, the engine will examine this data, throw away unnecessary pieces and retain necessary ones. I’ll explain this more in detail later at animations. If, after the game has been launched, a level launches where there are let’s say ten animations, the engine will load these 10 animations to the graphics memory after the first launch of the level. If a player plays this level, these animations will retain in the memory, so a contingent level restart or launch is just as fast as it was in QX. But if a player finishes that level (or leaves it by going to the menu) and another level launches, the engine will carry out the control and loading of the animations. From the previous level, there are still these ten animations loaded in the memory. Now let’s say that there are fifteen animations in a new level, eight of which are the same type as in the previous level, and seven are different. So, in the first step the engine checks to see what animations there are in its memory, and it’ll keep these eight that have retained there from the previous playing. It will “throw away” (release from the memory) two animations. And it will load seven new animations. As you might have noticed, despite the fact the amount of pieces of information is increased by one third compared to the previous one, during its start the engine will load only seven “new” animations and will be therefore faster than launch of the previous level. So in the graphics memory there is always only necessary data which is needed for a specific level. Owing to this dynamic system of data loading, QN may have only slightly higher memory requirements than QX! (We will talk later about why QN has higher memory requirements than QX if it has such an amazing administration of graphics memory.)

But don’t worry that loading of needed data might slow the start of level. As it’s been said in the paragraph above, only data which is really needed for the level is loaded and that’s only if it hasn’t been already loaded in the memory. The delay in the start of the launch if one level might be only as long as 100 – 500 milliseconds (so maximally half a second). I also dare to say that if I hadn’t written about this, no player would even notice it ;-).

© 2000-2024