Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

Bliss / Cas-Stunts track editor

Started by Cas, March 08, 2015, 01:16:12 AM

Previous topic - Next topic


A few bugs were found and I had to update the binaries. I've uploaded the updated Bliss 2.5.8 to

The GNU 64bit binary has been updated, but it now requires the newer libtinfo again. The 32bit binary is the same as before, so it still contains a couple of bugs. The DOS binary is not affected as the bugs impacted parts of the program that were not present in the DOS version. The Windows binary is updated and should work normally without bugs.
Earth is my country. Science is my religion.


Here is the GNU 64bit binary requiring libtinfo.5. For the 32bit one, next time I'll use the other PC I will compile it.


Thank you!  I could try to get cross compilation working, but the libtinfo problem would persist. I think I'll have to create a virtual machine exclusively for that! :S
Earth is my country. Science is my religion.


Thanks for your update! A 32-bit version for libtinfo.6 would probably be of limited use, since most Linux distributions do not support anymore x86 in their newer versions, such as Ubuntu 20.04 (although other ones like Mint do continue to support it). I attach the 32-bit version for libtinfo.5.


Linux Mint does claim to continue 32bit support as long as possible. I discovered that when I needed a latest version Linux halfway last year on a 32 bit laptop. (it was a pain in the but to find the right version to run the script)
I only needed it for one action because I was ameliorating the Windows version on that laptop. Which worked so I now have a reasonably quick Windows running on a cheap old laptop with 1x 1ghz core and 1GB memory..
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
Currently running over 20 separate instances of Stunts or 4D Sports Driving.


There was some debate over continuing supporting 32 bit also in Ubuntu 20.04, but it seemed how at last the ones that were contrary got the upper hand. In my opinion it would have been worthy to keep retro-compatibility, even if a huge majority of the CPUs from mid-2000s is x64. I hope that Mint will keep its promise.


Thanks!  I'll download the binary when I finish today's work. About GNU 32bit distros, I reckon at a certain point, it will be very rare to find one. The thing is that, as some projects that are important to a GNU system begin to abandon 32bit, the distribution developers are forced to using old pieces mixed with new pieces and we know how messy that is in an operating system that goes around shared objects. This is one of the reasons why I so strongly oppose shared libraries and 3rd party dependencies... They make it impossible to just keep your binaries in a drive and put them to good use years later. We can still run Stunts easily today because DOSBox emulates a stable system environment. This doesn't happen with GNU... and even with Windows, to certain degree.

In my opinion, the switch to 64bit from 32bit, while based on hardware, has been arguably the least necessary of the changes in CPU evolution. Besides, it is not true that in 32bit mode, you can't access beyond 4GB of memory. You just can't do it linearly, but you can use pages... Only good thing is I don't think there'll ever be a 128bit standard for home computers, ha, ha. Nothing against 64bit mode, of course. I just think it hasn't changed a thing from 32bit and we've had to go through the hassle of the upgrade for years. It's good, but it's the same. That's what I see.

Anyway, I'll confirm when I have updated Bliss packages! :)
Earth is my country. Science is my religion.


You're welcome! Indeed, 32-bit Ubuntu allows the so-called physical address extensions (pae), which result in 64 GB of memory accessible. The point is also how in the 2010s home PC market had not been so brilliant as in the 90s and in the 2000s, also since Moore's law has not been true anymore for years: I bought the PC from which I'm writing now at the end of 2009 and, after 11 years, it is still capable of performing the majority of the daily tasks I need, while my first PC back in 1992 would have been practically useless in 2003.

If, speaking of RAM, my PC from 1992 had 4 MB, my PC from 1996 had 32 MB (8x), my PC from 2001 had 256 MB (8x, later expanded to 512 MB), and my PC from 2005 had 2 GB (8x), by extrapolating 2018 PCs would possess 1 TB of RAM, while in fact nowadays with 16 GB you would have a machine which can be considered generally performant. I don't think we will ever see a computer with 2^64 byte of RAM...


I've uploaded and updated Bliss 2.5.8 with bug fixes. It's both up at and :)  Thank you!

It was clear that the trend in computer evolution had to have an end. We just didn't know when the industry would find a point of inflection. Usually, when they can't get you to buy bigger things, they just make them break sooner or invent something different and create a new fashion so that people move to a new item. Computer enthusiasts were many before the Internet-invasion. That brought so many people into our world most being completely not interested in computers in reality, which damaged the quality of the product. Now, all these people are moving the cell phones, but computer programming enthusiasts will remain with computers. I wonder if this will kill the classical computer world or if it will resuscitate it... or a mix of both. In the best case scenario, with the crowd moving to cell phones and less attention placed on desktop computers, the free software world will completely take over and PCs will return to being hacker/programmer/scientist/nerd-friendly.

I first had a 386 with 4MB RAM in 1993. After a year or so, I upgraded it to a 486 with 8MB. Then around 1996, I bought a Pentium 200MHz MMX with (I think) 16MB that I later upgraded to 32MB. At that moment, I got stuck. I had no money and because everybody else was turning to Windows and I was sticking to DOS, it was easy for me to continue using the same computer for many years. So my next computer I bought it when I had a job in 2005. It was a Celeron 700MHz with 128MB RAM. That was already the time of the Pentium IVs, but I wanted a Pentium III or similar because I had ISA hardware I wanted to use (SB AWE 64). DOS compatibility was important to me. My next computer was a used laptop I bought in New Zealand. I don't remember which CPU it had, but it had 512MB RAM in 2009. From that moment on, I stopped learning about new hardware. I just bought what there was at the moment. I've had a new desktop computer in 2012 and another in 2018, plus a laptop in 2017, which has never been my primary computer. The desktop computer I'm using now... I think it has 8MB RAM and four cores and it's AMD. And that's all I know, ha, ha.
Earth is my country. Science is my religion.


It's true, the computer that I am using now and which I use for the majority of my work is 10 years old.  This would have been unheard of in the 90s or early 2000s, even for me.

Quote from: Cas on January 08, 2021, 12:19:48 AM
The desktop computer I'm using now... I think it has 8MB RAM and four cores and it's AMD.

Which web browser are you using that runs on 8 MB of RAM? :P


Oopsie!  Ha, ha... That happens when you're talking about different generations of computers at the same time  ;D
Earth is my country. Science is my religion.


Hey Cas, thanks for the updates!

Two questions:
- which car should we use on 4AM.TRK, for the calibration?
- could you add "Raw, no metadata" as a default save option?


Uh, oh... I went to Bliss to make a few checks to be able to answer your questions correctly and I found new bugs :(   So, before I continue, these are the new bugs I found. Let me know if you guys observe them as well:

  • When loading a track, if instead of typing the file name, you click on a file, blank spaces appear and the track is not loaded
  • If you load a track by typing a filename, characters only appear if you type while the mouse cursor is over Bliss's window
  • Once you've typed the file name, if you hit Enter to load the track and the mouse cursor is over the grid, it'll cause the currently selected brush item to be inserted on the track

    Besides these, there's what you, Dreadnaut, have pointed out. It's a text bug. Originally, Bliss could only calibrate with the track 4:00am and the Porsche March Indy. Now it can calibrate with any track you want, but unless you have a currently working track on the grid, it will default to 4:00am. If you do have a track there, it'll clearly state "this track with Porsche March Indy", but otherwise, it'll just say "4:00am". It should say it's with the PMIN too. I'll fix that.

    About setting RAW to default, I can add that option to the menu. It should be easy. But even though it's not in the menu, that is already available!  Just edit the configuration file. Where it says "format=bliss" or whatever, change it to "format=none" or "format=trackblaster". Let me know if that works for you.
Earth is my country. Science is my religion.


I just tested the Windows version and the behaviour of the bugs you mentioned is slightly different:

  • When loading a track, if you click on a file, blank spaces appear and the track is not loaded, as you mentioned.
  • You can load a track by typing the file name and the characters will appear regardless of the mouse cursor position, however if you press Enter, the track will not load until you move the mouse cursor over the Bliss window.
  • When pressing Enter to load a track, the currently selected brush item is not inserted on the track, even when the mouse cursor is over the grid.


Uhmm... yes, I expected it could be possible for Windows to do differently. This is because of a special GNU/Linux-based function I implemented for the UTF-8 update. I've just had some work on the code and I think I solved most of the bugs. One of them, I realised was produced when I fixed another bug. Adding features and fixing bugs creates bugs :(  I want to get a stable version once and for all. Once I have that, I'll call it 2.6.

EDIT: There!  I quickly uploaded a snapshot of version 2.6 which should fix these things and implement the feature requested by Dreadnaut. It's at, as usual. Version 2.5.8 will continue to be available until 2.6 goes out of the beta, so you can get both from there. Afullo: since this is a quick snapshot, I don't think we need to update the binaries for the right libraries this time. Once it's stable and no more bugs are found, we can do it. What do you think?
Earth is my country. Science is my religion.