. /../Cryxtels Reborn (version.../ 123
written by E_net4 on Aug 29, 2013 23:56
Not long ago, I thought yet again of the possibility of porting Crystal Pixels to make it work on modern Windows or Linux systems. Well, once I had a simple look at it, I decided to give it a go!

This is the result. Cryxtels running on Linux!


Here's a snapshot taken from the game itself:


My approach to this port follows some guidelines. Since the code actually works, I am focused on keeping as much code from the provided open-source version as possible. When I can't, it must be replaced with something that will work on nearly any machine. In addition, I am using the SDL library for all the I/O, which means the program can later be cross-compiled to platforms supported by SDL.

I may also mention some of the challenges of porting the code:

- Nearly all of the code is in italian. Even when identifiers don't specify their meaning, sometimes I need some help from Google translate to sort things out.
- Inline assembly! This was one of the toughest tasks. Some of them are used to call interrupts (for calling the system or the MS-DOS API), and may be replaced with the appropriate function calls from C or C++ system libraries. Other pieces however, make some supposedlyfastbecauseassembly algorithms, such as the line drawing seen above. On that, I had to manually convert it to C++. The compiler should optimize it anyway, not to mention there's definitely no need to worry about this program's performance.
- Speaking of libraries, even some of the C libraries were outdated and could no longer be used. Even the concept of a near/far pointer is no longer applicable. All far pointers were converted into just normal pointers, and libraries such as <dos.h> had to go away. I am replacing all function call with ones that make the same task.
- Global variables! Global variables everywhere! I still don't know what I'm going to do with so many global variables!
- Not quite a challenge, but since the original code was made to be compiled on a C++ compiler, so am I using actual C++ code. It helps, sometimes. It also makes a better excuse for using a C++ compiler.

And finally, accept my apologies on not performing this over Noctis. When I started tinkering with this code, I didn't at first think of Noctis, to be honest, but there is more of a reason than that: Since the porting process isn't a simple one, doing it on a much bigger program such as Noctis would take much longer and most likely make me give up.

The latest development can be found on GitHub: https://www.github.com/Enet4/cryxtels

It's nearly feature-complete. There's no audio support, but all other features should be there. The pixel definitions are compatible with the English format, the solid box primitive was manually added, and the primitive limit was changed from 40 to 100 (like in the English version of Cryxtels). Future versions may not exist, but if they do, they may perform fixes, tweaks, strengthen the program with better element allocation and perhaps add new features. Your feedback is welcome at this point.

And here's an older version:
Version M1.00 for Linux 32-bit (SDL 1.2 runtime libraries needed, not included):
cd/zips/E_net4/cryxtels_m100_linux32 (587 Kb)

Windows version of M1.00, compiled by Selbio.
cd/zips/Selbio/cryxtels-win32 (2602 Kb)
└> last changed by E_net4 on June 05, 2016 at 11:55
i haz title: speed-g-dof
written by Speeder on Aug 30, 2013 00:03
Whoa, really cool!

I wish I had coded stuff like this to one day have fandom that work on it

Also I wish I was good as you two!
ah didn't learn anything!
written by Selbio on Aug 30, 2013 03:59
E_net4 said:
- Inline assembly! This was one of the toughest tasks. Some of them are used to call interrupts (for calling the system or the MS-DOS API), and may be replaced with the appropriate function calls from C or C++ system libraries. Other pieces however, make some supposedlyfastbecauseassembly algorithms, such as the line drawing seen above. On that, I had to manually convert it to C++. The compiler should optimize it anyway, not to mention there's definitely no need to worry about this program's performance.
One of the original reasons, of course, is that BC++ was a _horrible_ compiler. My Noctis with a lot of assembler replaced with straightforward C is pretty painful to play in spots.

E_net4 said:
And finally, accept my apologies on not performing this over Noctis. When I started tinkering with this code, I didn't at first think of Noctis, to be honest, but there is more of a reason than that: Since the porting process isn't a simple one, doing it on a much bigger program such as Noctis would take much longer and most likely make me give up.
I started ripping out assembler/syscalls and replacing it with C in NIV+ last year. I eventually got sick of deciphering Alex's "clever" hacks and burnt out on it. I doubt I would have seen anything outside of the increasingly-slow DOS verification build for months. I certainly think you made the right choice.

Good luck!
i do my own stun-- avatars
written by Albeyamakiir on Aug 30, 2013 06:26
I always got the impression that Alex was one of those programmers who would just write stuff, damn the conventions and guidelines, making his code incomprehensible to anyone other than him (probably even his future self would be totally confused).

Interesting to see this basically confirmed.
written by Cryoburner on Aug 30, 2013 09:01
It looks good so far. Have you done much past the loading screen and line rendering yet? I do notice that the lines still need that additive effect added. From the look of it, the original renderer likely draws the lines in monochrome, adding the values when they overlap, then displays them with a palette that that goes from black to blue to white for that 'crystalline effect'. Also, there are fade and lattice effects on the title screen, though I don't think they appear in the game itself.

Crystal Pixels runs pretty well in DOSBox, but it should be nice to have an updated version running natively. At the very least, some minor additions like the ability to remap controls and allow for correct display at alternate aspect ratios would be nice. One thing to remember is that Crystal Pixels originally wasn't intended to use square pixels. Much like Noctis, while the resolution was a 16:10 aspect ratio (320x200), that was meant to be scaled to a non-widescreen display, so things might appear a little stretched horizontally at its native resolution. I thought the resolution was intended to be stretched to 4:3, but doing some comparisons of screenshots, namely of Fottifoh on the title screen and a glowing orb in-game, it appears to actually be closer to 5:4. Whether this was intended or not, or just the result of some rounding error, is difficult to say without looking into the code. However, other elements in the game, like the skybox textures, don't appear to be intended to get scaled. The routine to distort the image is likely built into the line plotter. Taking a quick look at the code, the values of zbasex and zbasey in fast3d.h might be responsible for distorting the line output, but I didn't test or look into it very far. It might be worth just replacing the transformations from world space to screen space with calls to SDL's functions, if you're using that. And if allowing the game to run at a true widescreen aspect ratio, ideally the horizontal field of view should be expanded, otherwise you would be reducing how much can be seen vertically.

Are there any plans to increase resolution? You'd probably need to make the lines thicker to make that work though, otherwise things wouldn't look much like they were originally intended to. Even that might not still look quite the same though, so it might just be better to do pixel doubling.
written by E_net4 on Aug 30, 2013 10:50
Cryoburner said:
It looks good so far. Have you done much past the loading screen and line rendering yet? I do notice that the lines still need that additive effect added. From the look of it, the original renderer likely draws the lines in monochrome, adding the values when they overlap, then displays them with a palette that that goes from black to blue to white for that 'crystalline effect'. Also, there are fade and lattice effects on the title screen, though I don't think they appear in the game itself.
Well yes. I mentioned in the chat not long ago that I now converted the assembly code that makes the intro screen prettier. So yes, it's meant to have some sort of blur effect, and it seems to be working now. The crystalline effect you mention is only the combination of how elements are drawn to the video buffer and the color palette being used (which is generated at the beginning of the program). I had to tweak both the palette and the drawing procedures.

Cryoburner said:
Crystal Pixels runs pretty well in DOSBox, but it should be nice to have an updated version running natively. At the very least, some minor additions like the ability to remap controls and allow for correct display at alternate aspect ratios would be nice. One thing to remember is that Crystal Pixels originally wasn't intended to use square pixels. Much like Noctis, while the resolution was a 16:10 aspect ratio (320x200), that was meant to be scaled to a non-widescreen display, so things might appear a little stretched horizontally at its native resolution. I thought the resolution was intended to be stretched to 4:3, but doing some comparisons of screenshots, namely of Fottifoh on the title screen and a glowing orb in-game, it appears to actually be closer to 5:4. Whether this was intended or not, or just the result of some rounding error, is difficult to say without looking into the code. However, other elements in the game, like the skybox textures, don't appear to be intended to get scaled.
I really didn't think into the possibility of things being "naturally" scaled in one axis. Right now all pixels are square, and that's it.
Cryoburner said:
The routine to distort the image is likely built into the line plotter. Taking a quick look at the code, the values of zbasex and zbasey in fast3d.h might be responsible for distorting the line output, but I didn't test or look into it very far. It might be worth just replacing the transformations from world space to screen space with calls to SDL's functions, if you're using that. And if allowing the game to run at a true widescreen aspect ratio, ideally the horizontal field of view should be expanded, otherwise you would be reducing how much can be seen vertically.
I didn't need to use any projection functions, because the whole process of converting a 3D point to a projected 2D point is in C (and it's working, so no need to mess with it for now).

Cryoburner said:
Are there any plans to increase resolution? You'd probably need to make the lines thicker to make that work though, otherwise things wouldn't look much like they were originally intended to. Even that might not still look quite the same though, so it might just be better to do pixel doubling.
All routines were hard-coded to work on a 320x200 screen, but I'm slowly replacing some of the trivial numbers into something that depends on a specific width and height. I could try increasing them and see what happens, but you're right about the lines becoming less thick. But well, at least the pixel doubling is planned, else my eyes would hurt after a while.
written by E_net4 on Aug 30, 2013 17:41
Update!
Nearly all code has been migrated now. There are still some chunks of asm code here and there, but there shouldn't be that much labour left before it becomes playable.

You can "sort of" control The Fly now, land on pixels and walk on them. Pics.





I also forgot the default key mappings of the game. I guess I can check that later.
standing on my title
written by Gligar on Aug 30, 2013 17:45
Chiming in here to say that this is looking good!

I do have to agree with Cryo about increasing the resolution. I'm sure no-one wants to have squint at a 320x200 window to play with this
written by Cryoburner on Aug 31, 2013 13:29
It looks like it's getting pretty functional, and the line effect looks close to how it should, though I notice that at least in those screenshots, it's only using half the color values that it should, with colors ranging in brightness from 0 to 127, rather than 255. I imagine you may have noticed this though. : P

E_net4 said:
I really didn't think into the possibility of things being "naturally" scaled in one axis. Right now all pixels are square, and that's it.
Yeah, I suspect this should just be a matter of increasing the horizontal field of view, while leaving the vertical field of view as it is. I believe that may be controlled by that 'zbasex' variable I mentioned previously, which if increased to something like 240, might fix the field of view for the existing 16:10 aspect ratio. Doing that might make the already barely-readable text in the cockpit of the fly even less readable though, if it too gets adjusted. On that topic, it would be nice to eventually have some sort of togglable zoom-view of the controls, or the ability to lean in to view them closer. Small vector fonts at 320x200 resolution don't tend to be very readable. : P
written by E_net4 on Aug 31, 2013 13:41
Cryoburner said:
It looks like it's getting pretty functional, and the line effect looks close to how it should, though I notice that at least in those screenshots, it's only using half the color values that it should, with colors ranging in brightness from 0 to 127, rather than 255. I imagine you may have noticed this though. : P
Well yes, I did. I even changed some of the palette's parameters, but maybe a few other pieces of the code are involved in the possible decrease of contrast from the original.

Cryoburner said:
E_net4 said:
I really didn't think into the possibility of things being "naturally" scaled in one axis. Right now all pixels are square, and that's it.
Yeah, I suspect this should just be a matter of increasing the horizontal field of view, while leaving the vertical field of view as it is. I believe that may be controlled by that 'zbasex' variable I mentioned previously, which if increased to something like 240, might fix the field of view for the existing 16:10 aspect ratio. Doing that might make the already barely-readable text in the cockpit of the fly even less readable though, if it too gets adjusted. On that topic, it would be nice to eventually have some sort of togglable zoom-view of the controls, or the ability to lean in to view them closer. Small vector fonts at 320x200 resolution don't tend to be very readable. : P
There may be room for enhancements once I actually make the original game work. Let that be in the queue for now.

As for another status update... with some nearest-neighbor scaling to another surface, I managed to enlarge the window. How's that for visibility?
cd/pngs/E_net4/cryxtels_reborn_4 (34 Kb)

Edit: All right, I fixed the contrast, it's much brighter now (like in the original). I also forgot to mention that creating pixels seems to be working. Here's The Fly carrying a pixel.
└> last changed by E_net4 on August 31, 2013 at 15:55
written by E_net4 on Sep 01, 2013 22:06
Last post was overused a bit too much, so allow me to double post this time.

Status update!

After succesfully converting the asm code responsible for drawing the pixel dots from a distance ( the screenshots I've been giving you were looking a bit dull, weren't they? ), I went for the maximum resources to test and see any effects on performance (and to introduce some bliss to my eyes). Suddenly, a wild segmentation fault appeared. This happened whenever I inserted a high number of pixels or objects. After some debugging, I reminded myself that the size of int variables wasn't the same back then (it was only 16 bits). I quickly modified the memory allocation instructions to use the effective size needed. No more issues on that.

In addition, I got the mouse interaction working. The cursor will become invisible while working with the mouse, but you might still be able to lose focus from the app's window and return to it normally. In addition, going to keyboard navigation mode makes the cursor visible again.

So here's another shot: 500 pixels from above. I also felt no performance decrease with the debug binaries, so I assume performance won't be a problem either.


What's next: well, there's only one more piece of assembly code to convert. It's the one that draws the skyboxes. It's a bit trickier because of the calculations it performs and the direct reading from the .ATM files from the asm code. Next is to make sure all controls are accessible, including being able to pick up either light or heavy objects, climbing, loading and saving the game, writing to text boards, and anything else that I missed.
written by Logicalerror on Sep 02, 2013 14:23
I always wondered if someone would go down the rabbit hole of replacing Alex's assembler with modern more modular code. I've thought about about trying it myself, but currently I've barely learned regular input and output in C++.

I'll be watching to see how this shapes up. Good luck
written by E_net4 on Sep 02, 2013 15:16
Logicalerror said:
I always wondered if someone would go down the rabbit hole of replacing Alex's assembler with modern more modular code. I've thought about about trying it myself, but currently I've barely learned regular input and output in C++.

I'll be watching to see how this shapes up. Good luck
The initial point is to make the application runnable in a modern system by replacing outdated code. Sure I "prettified" some of the code with more functions and source files on the way, but a complete restructure of the code would be excruciatingly painful. The main() function, for instance, contains over 1000 lines. And if I move relevant parts into functions, I risk losing access to variables that were declared somewhere in main. This was probably what made Alex create so many global variables. Yeah, things can get pretty ugly around here.

Nevertheless, thank you all for the support! I hope to publish an initial version of this port's source as soon as I find it sufficiently "feature-full". Loading and saving seems to be working now. So the one feature that is critically missing is the skybox rendering. I haven't seen the code for writing to text boards, nor to pick up heavy objects. It makes me wonder if the Italian version has these features at all, which I think it should.
written by Logicalerror on Sep 02, 2013 19:55
Well... by modular I suppose multiplatform would be a better word.
written by E_net4 on Sep 02, 2013 23:17
Ok, one more status update. See below.


But there's more! Loading and saving works seamlessly. I have also converted the pixel definitions format to English, just like how it's seen in the English version of cryxtels. This should make the latest pixel definitions compatible with this modern version. I also implemented the solid block element that was only added later for the English version.
With all this, I suppose what remains is picking up heavy objects and writing to text-h and text-v elements. Once that's done, I suppose it'll be ready for an initial release.
reading this thread
no members are reading this thread
. /../Cryxtels Reborn (version.../ 123
53076, 11 queries, 0.142 s.this frame is part of the AnyNowhere network