gauntman

Late to the party, but congratulations on this, Sheddy! It has been a long haul. The results are amazing.

This was indeed terrible event - a great contributor to the 8-bit scene, lost early. My condolences and prayers to family and friends.

You are advancing $d1 to much -- in single resolution mode, Player 1 is 256 bytes away from Player 0 -- so, only increment $d1 once. actually, looking at the code, you could use direct storage instead of a zero page, something like this: ldx #0 ldy vpos drawLoop lda shape,x sta $8200,y lda shape2,x sta $8300,y inx iny cpy #10 bne drawLoop You might want to flip your shape data, then you could decrement x instead of increment, saving a compare. But get stuff working first, optimizations can come later.

Some nice graphics there, thanks!

I really hate to drop NTSC support, since I am an NTSC user... I was always sad to see a cool game that I could not play on my own system back in the day. Of course, now most people probably can/do use emulators, but I still really would like to squeeze this into a game that I could have played back in 1986 on Christmas day! If worse comes to worse, I probably could double buffer and drop to 30 frames/sec - but that would require reworking a lot of logic code and the graphics system (the original UWOL worked at 25 frames/sec).

I am writing this in assembly, using the original C source as a guide. The actual game logic was not too hard to port - I am struggling right now with getting softsprites running quickly enough for NTSC. Currently, I am working on turning off the O/S to get more memory, which should allow me to unroll more code.

Does anyone have a bare-bones replacement kernel that they would like to share? I am looking at needing to put one in place to gain access to extra RAM.

A fairly major bug has been reported and fixed. rmtmerge v1.0 did not properly handle song references to undefined tracks (this can happen with empty tracks). Version 1.1 that addresses this problem is attached - all users are encouraged to upgrade to this version. rmtmergev11.zip

Hi all, Here is a utility that may come in useful when pulling together multiple RMT songs into a single file. I wrote this as part of the UWOL project, where we had 10 songs. Merging the RMT files can save space, particularly if the files utilize many of the same instruments. This saved around 500 bytes. Here is a snippet from the readme file: Basic Usage =========== First, load each of the RMT files you wish to merge into RMT, and then save as rmt .txt files ("TXT song files"). rmtmerge only works on rmt.txt formatted files, not on native rmt files. Once you have saved all of the files you intentend to merge, run the following command line: rmtmerge file1 file2 file3 file4 This will load all the files on the command line, merge them, and save the result as merged.rmt.txt Next, load the merged.rmt.txt file in a text editor and remove any extraneous [MODULE] sections (there should only be one in a legal rmt.txt file). Finally, load the file in RMT, go to the Song menu, select "All size optimizations". Enjoy! rmtmergev10.zip

Slowly... the new year came a bit earlier than I anticipated However, I as a consequence of some of the work, I do have an RMT merge utility... see the programming subsection for details.

And.... I am back. Sorry for the scare. I was indeed on vacation. There are some parts of the world even in the mighty US of A that don't have Internet connectivity (well, or dial-up only). I admit I was starting to go through withdrawls. We should be hearing some exciting UWOL news by the end of the year.

And for graphics, there is G2F and I will put in a short commercial message for EnvisionPC.

Of course! I hadn't thought it would be that simple, I thought that the artifacts might be too noticable -- I will try at 1/12 and 1/6 and see if the music still sounds right. Otherwise, I will look at the more invasive suggestions from Rybags.

Hi all, Looking at the rmtplayer source code, I don't see anywhere that corrects for NTSC/PAL timings. How can I play a song at PAL speeds on an NTSC machine? Note: I want to be doing this during gameplay on a screen with pretty heavy DLI useage. Currently, I am calling the routine during the deferred VBI... moving to a busy loop watching VCOUNT is undesirable. How are other people doing this?

I recently needed RMT for a project I have been working on in ATasm. Attached is a port of RMT 1.28 for the ATasm assembler, in case someone else also finds this useful. From the readme.txt file: This is a quick-and-dirty port of RMT 1.28 to the ATasm cross-assembler. The original assembly code is by RASTER/C.P.U. Any errors in this version have probably been introduced on my part. This port has not been extensively tested yet - certainly not under all possible permutations, so there may still be some problems. The sfx demo from the RMT distribution has been also been converted to ATasm and is included as an example of how to use the source. One difference in usage compared to the XASM/MADs version is that ATasm will include the RMT binary directly instead of linking it. This requires the RMT executable header to be stripped. The header is simply the first 6 bytes of the file. Included is a very simple C program that does just that. This means that you will need to remember the address specified when exporting a song. Then, in the source do the following: *=$4000 ; or where ever the export was set .incbin "song.rmt.bin" ; a regular RMT export, with first 6 ; bytes stripped off As a general rule of thumb, if the sound is not working, probably you forgot to strip the header from the RMT file. rmt128-atasm.zip