Messages

Thank you, CTG!   I'm fixing the bugs and I'll try to publish the next beta tonight!

   Thank you, Duplode!  You've done a lot of testing. You found some undocumented keys and bugs I hadn't noticed!
I compiled the Windows version for 64bit (I actually had my brother do it for me, since I use Linux), but I could compile it 32bit if necessary. The Linux version is 32bit because I'm currently using a 32bit Linux, but would like to upgrade and probably next versions will be 64bit.
    What Linux distro are you using?  Were you able to run the binaries without any dependencies expect for the 32bit lib? I'm interested in knowing more about this. The error about file name duplication, I had not noticed, because I did most of my tests under GNU/Linux, but now that I read it, I know exactly why it happens. I will have it fixed and upload the update. It's not hard to resolve. The editor can actually combine track elements already, but I compiled it without that option, because I hadn't added the switch yet and I preferred the default to be more like the original editor. Next version will include at least a key shortcut to switch editing mode. There is also an option for not showing the terrain warnings. It can be used for checking what's "under the yellow box". I'll also include that in the next upload.
    About the high CPU usage, I've noticed that in some of my programs and I really don't know why that happens. I think I need to include more idling time in it. I can see DOSBox takes some time to load the DOS version. I believe it is because I load the Targa graphics byte by byte, as the screen format is different from that of the graphics. I could make this work faster by changing the file format, but the file would be 25% larger and the loading time would only vary significantly under DOSBox. I'll consider it

[Bliss 2.6.1]

Hi, folks!  I had been off for a long time and recently visited the forum, found it still very active, so I decided if I wanted to come back, better not do it empty-handed!  Then, I started to work on a new track editor and here I'm bringing you the first beta version. I hope you like it. I'm still working on it, so please do tell me of any bug or general suggestion.

EDIT:
Current latest version: Bliss 2.6.1 2022-01-14
Download from site: https://www.raceforkicks.com/bliss
Or from NotABug repository: https://notabug.org/xlucas/bliss/releases (down as of today)
Supports GNU/Linux 64bit, Windows, FreeDOS and DOSBox
GNU/Linux 32bit is still compatible and you could compile from source (which is included) if you want the binary for it.
I'm unable to upload the ZIP file directly to the forum because it's larger than 1MB.

NOTE for GNU/Linux users: By now, I think most distros have switched from libtinfo.5 to libtinfo.6. The binaries are providing use the latter. If you're running an older distro, you may need to upgrade your libtinfo.

Please feel free to host a copy of Bliss in your sites, guys, so there are as many places to download it from as possible.

Sure!  I'll post it. It's still in beta version, but it already does all the basic things it has to do.

That'd be great!  I'd be glad to contribute to it, and/or participate. If somebody to do the replay checking and scoreboard update is necessary, I'm also eager to do it myself. Whatever is necessary to make it happen
These last days I have been thinking a lot about Stunts. I have more time now so I've put some attention to it again and I've made a new track editor. What is the track editor being used the most now?  I remember TB was popular back then.

So how about Invasion?  I can't see it in the forum here. Where can I find out about it?

Ha, ha... yes... sadly, this project didn't work as expected at that time. I'll probably try facing it a different way in the near future. I really thought I had resolved it back then

People. I had another copy of Stunts 1.1 in the past that didn't do this, but the one I'm using now, I'm pretty sure I downloaded from here, so maybe you can give me a hint. The thing is that, whenever I enter the game, it's always set up to not show any scenery. I can disable it, but my settings are not saved, so if I exit and reenter, I need to change the setting once more. Any way around that?

Hey, guys!  Nice to see you all again here!!
Maybe you don't even remember by now. I was wondering if any of the currently running competitions is a OWOOT, to give it a try. In my times, I used to play on WSC. Not that I haven't been to the forum since, but almost...

Gracias. Ya veré el próximo mes de enviar un mejor tiempo

Sí... y las teclas son más chicas y delicadas... ja, ja....
Creo que para el próximo mes, pasaré las cosas de Stunts a la compu de escritorio... aunque después tenga que estar transfiriendo archivos... pero juego mejor.

Acá ando, aunque ahora jugando desde la compu portátil no es igual de cómodo. ¿Cómo están?

Bueno... he vuelto, por lo menos, por el momento.. y ya mandé mi primer tiempito

Thank you... I'm installing RSSI.... I'll try to figure out how it works. I once used IRC through a web-based interface, but I don't remember where it was.

I've been researching the memory structure of Stunts as it loads and I found the following data. Many of this, you probably have already figured out, but other stuff might be useful:

- Stunts has HDR, DIF and COD files for MCGA, TDY (Tandy) and CGA, but the DIF file is replaced by a CMN file for EGA. All COD files for some reason are about 64K long (though never exactly), DIF files are about 16K and the CMN file is about 128K. This cannot be just a coincidence!  HDR files are unmistakenly EXE headers. They are 30 bytes long, but nevertheless correspond to EXE files whose code starts at byte 512. The space in between does not contain any code update, though. COD, DIF and CMN files are slightly compressed with a procedure that looks like a very basic kind of Huffman. This is exactly the same procedure used for 3D shapes compression, so it is already known, as cars are already being edited!!  The actual sizes of decompressed codes are specified at the second byte of these files and do not match with the size estimate contained in the headers, which is much bigger.
- STUNTS_K.EXE, the crack, is lightly encrypted. The encryption system can easily be removed with UNP. The unpacker will ask for a passcode. First thing I thought worked: it's just "stunts_k". The resulting file is smaller than the encrypted one.
- STUNTS_K.EXE is loaded, keeping its environment MCB and code MCB. On top of it, STUNTS.COM runs, which also preserves its environment, reads the configuration file and loads LOAD.EXE into memory half-manually, apparently upgrading the code depending on the graphics card selected. LOAD.EXE runs. Environment is preserved again. LOAD.EXE reserves a lot of heap and no dynamic memory is allocated for variables. Only one extra MCB is allocated, but it is used to store only the sound driver, which starts at byte zero. If no sound card is selected, PC-Speaker driver is loaded anyway, but is not used. This last MCB takes up all the rest of the available conventional memory, even though it is not necessary.
- I have verified that the data contained in MCGA.COD and MCGA.DIF is not found in memory while Stunts is running. This is a confirmation that the information is compressed.
- Some variables are stored at positions that seem to be also variable respect to LOAD.EXE's starting code offset, even though they are within the same MCB. This is still a kind of mistery to me

Hope it's useful

[I don't even remember how to use an IRC]

Great!  Well, I'll tell you what I'm good and bad with, what I have at hand and what I need to know to be able to help.

- I have always been part of the... uh... "resistance", he, he, against Windows, so I have all these years kept on working for DOS. I'm pretty comfortable to it, although I really like and use Linux as well (I have Ubuntu), but I'm still not as good at it as I am with DOS.
- For real-mode high-level, I've worked with Turbo Pascal, Borland C++ and QuickBASIC. I'm specially comfortable with the last two. For low-level, I understand any assembler, but for writing I'm much faster with FASM. For protected-mode high-level, I've been working with FreeBASIC and I've tried it under Ubuntu too. I would like to improve there as well.
- I know very little about network and internet stuff, so I don't even remember how to use an IRC, but I'm willing to participate there if you tell me how.
- I have (some times intentionally) avoided using object-oriented programming, so I am not familiar with languages that develop exclusively in that area. I am used to programming graphic routines low-level and I know how to access old SoundBlaster cards through ports too. I am used to doing that myself, so I don't know about libraries and I'm inexperienced about loading third-party modules in my code.
- I understand the structure of DOS EXE files and know about opcodes
- I am weak about low-level protected-mode programming

So I hope I can be helpful here. It's very good to have somebody else also trying to unwrap all this code. I've been working on analysing Stunts internal variables to block replay handling and I partially succeeded, except that I found some stuff to be system-dependent. Now that car-editing is already possible, the next step (apart from replay-handling control) would be enhancement of track edition, by allowing variable-size maps and more track objects. We need to isolate the (kind of crazy) pseudo-Newtonian force/collision engine, the track/replay file analysis code and the sound and graphics hook-points. About the sound, I've already been working on that. OK... please let me know how we can get in touch. I can pass you my e-mail and Skype IDs and will be glad to participate in the IRC

My goodness!

Everytime I'm busy for a few weeks, I come back and there's magic going on!  I would be very happy to help!  Time ago, I had been thinking of a method for decompiling the whole Stunts code (mainly LOAD.EXE). I had already UNPacked the EXE and noticed the structure of the HDR, COD and DRV files. Note that the DRV files are the sound libraries, each of them is supposed to be loaded at the beginning of a segment (offset zero) and starts with a series of jumps to each of the sound functions. I am currently working on a project for FreeDOS that should provide a sound API for DOS and enable some old games to have sound again. Stunts is one of my examples of how this can be accomplished, by replacing the DRV files (specially the AdLib one) with patches that redirect the functions to the new API, called CPOS/NSS.
But back to the decompiling... I am willing to help, but would suggest the following:
1- Do not abandon the game support for pure DOS!  This is an opportunity to support the FreeDOS project. Stunts was born a DOS application and it can still be improved with 32bit code without necessarily having to separate from DOS. Make sure any new code can also be compiled to run under pure DOS. I can dedicate to that myself.
2- MASM and TASM are not very comfortable to receive decompiled code because of the way they structure the sources (ASM files)... having lots of required directives. I strongly suggest Flat Assembler: http://flatassembler.net
3- What do you need help with?