Jump to content
IGNORED

New game project: Jetpac


Vorticon

Recommended Posts

@Tursi,

 

You're correct of course, however, in TF, the cartridge has two entries on the cart menu - one for 40 column mode and one for 80 column mode. Each bank would still have two identical cart headers, but with only one entry (the 40 column entry) defined in each bank, rather than two. :)

Link to comment
Share on other sites

Here's a snapshot of the game with the faster monsters. I must admit that this looks better even though now my score is abysmally low, so I'm making it official as version 0.85. I also hunted down and squashed the intermittent 2 player bug and made a couple of minor enhancements to the code along the way.

 

https://youtu.be/gUqSojbV2aY

Ahhhhh Haaaaa, that's the Jetpac I'm talking about, Compared to the ZX Spectrum, VIC 20 and BBC Micro version-this one is the best, it narrowly beats the Spectrum version due to the lack of attribute clash, all we need now is some sound-and let's face it, it won't take much to beat the Spectrum on the sound front ;)

 

Congratulations once again on a great coversion.

 

P.S, what's next?

Lunar_jetman_title.gif?

  • Like 1
Link to comment
Share on other sites

Noted :)

 

I've already produced a stripped-down TF cart image (just 16K at the moment) that has a single Jetpac entry on the cart selection screen. It boots straight into TF. The auto boot code has been removed. It will simply execute a single word in the dictionay (i.e. JETPAC) upon startup and the game will start. I'll probably finish it this weekend. If the game had some sort of secret keypress on the game selection screen to drop out of the game you'd land in the full TF environment and would be able to write Forth programs!

 

Too cool :-)

  • Like 4
Link to comment
Share on other sites

That is just great! Now I need Omega to come up with a cool cart label :)

One thing I should mention is that the bitmap splash screen, essentially the original Jet Pac one with just credits modifications, will need to load from disk for the disk-based Jet Pac since I don't have 12K of available RAM for it. That said, I wonder if there is a way compress the color and PDT image files into something like 8K so they can fit in low memory... I'll do some research on this.

  • Like 2
Link to comment
Share on other sites

That is just great! Now I need Omega to come up with a cool cart label :)

One thing I should mention is that the bitmap splash screen, essentially the original Jet Pac one with just credits modifications, will need to load from disk for the disk-based Jet Pac since I don't have 12K of available RAM for it. That said, I wonder if there is a way compress the color and PDT image files into something like 8K so they can fit in low memory... I'll do some research on this.

 

Tursi's Convert9918 can RLE compress the splash screen to just under 6K. The attached XB program, generated from Convert9918, is a bit longer because it also includes the XB to display the image.

jetpacxb.bas

  • Like 1
Link to comment
Share on other sites

 

RLE - no header is attached. The files are RLE encoded as such:
Count Byte:
- if high bit is set, remaining 7 bits indicate to copy
the next byte that many times
- if high bit is clear, remaining 7 bits indicate how
many data bytes (non-repeated) follow

 

 

Rasmus, in looking up RLE compression, there seem to be several variants of it. The original RLE simply had 2 byte packets, the first one indicating the number of repetitions and the second the byte to be repeated. This is a bit different from what you indicated. I'm having problems extracting a usable image from the compressed files, and I want to make sure I am using the right decompression scheme...

Link to comment
Share on other sites

Rasmus, in looking up RLE compression, there seem to be several variants of it. The original RLE simply had 2 byte packets, the first one indicating the number of repetitions and the second the byte to be repeated. This is a bit different from what you indicated. I'm having problems extracting a usable image from the compressed files, and I want to make sure I am using the right decompression scheme...

RLE is just a term, not a file format. It applies to anything that compresses by encoding a series of bytes, thus "run length encoding". Rasmus posted the system I'm using from the Convert9918 documentation. :)

 

I sent the unpack C source code last night, that's proven working.

Link to comment
Share on other sites

RLE is just a term, not a file format. It applies to anything that compresses by encoding a series of bytes, thus "run length encoding". Rasmus posted the system I'm using from the Convert9918 documentation. :)

 

I sent the unpack C source code last night, that's proven working.

 

I am also interested in the details of your RLE method. Is the 7-bit count value the actual count - 1, i.e., does 0 – 127 map to actual counts of 1 – 128?

 

...lee

Link to comment
Share on other sites

I am also interested in the details of your RLE method. Is the 7-bit count value the actual count - 1, i.e., does 0 – 127 map to actual counts of 1 – 128?

No, it's not even that smart, it's the actual count:

 

void RLEUnpack(unsigned int p, unsigned char *buf, unsigned int nMax) {
	int cnt;
	unsigned char z;

	VDP_SET_ADDRESS_WRITE(p);
	cnt=nMax;
	while (cnt > 0) {
		z=*buf;
		if (z&0x80) {
			// run of bytes
			buf++;
			z&=0x7f;
			raw_vdpmemset(*buf, z);
			buf++;
		} else {
			// sequence of data
			buf++;
			raw_vdpmemcpy(buf, z);
			buf+=z;
		}
		cnt-=z;
	}
}

void ldpic() {
	// loads a picture - we aren't actually loading from disk
	// we are un-RLE-ing the image from ROM
	RLEUnpack(0x0000, TITLEP, 6144);
	RLEUnpack(0x2000, TITLEC, 6144);
}
  • Like 1
Link to comment
Share on other sites

Here's the assembler code I used in Sabre Wulf:

********************************************************************************
*
* RLE decode to VDP RAM
*
* The files are RLE encoded as such:
* Count Byte: 
* - if high bit is set, remaining 7 bits indicate to copy
* the next byte that many times
* - if high bit is clear, remaining 7 bits indicate how
* many data bytes (non-repeated) follow
*
* R0: Destination VDP RAM address
* R1: Source CPU RAM address
* R2: Number of target bytes to decode
*
RLEDEC     MOV  R11,*R10+             * Push return address onto the stack
	   BL	@VWAD                 * Set up write address
RLEDE1     MOVB *R1+,R3
	   JLT	RLEDE3
*	   Copy next n bytes
	   ANDI	R3,>7F00
	   SWPB	R3
	   S	R3,R2
RLEDE2     MOVB	*R1+,@VDPWD
	   DEC	R3
	   JNE	RLEDE2
	   JMP	RLEDE5
*	   Copy next byte n times	   
RLEDE3     ANDI	R3,>7F00
	   SWPB	R3
	   S	R3,R2
	   MOVB	*R1+,R0
RLEDE4     MOVB	R0,@VDPWD
	   DEC	R3
	   JNE	RLEDE4
RLEDE5     MOV	R2,R2
	   JGT	RLEDE1
*	   Return
	   DECT R10                     * Pop return address off the stack
	   MOV  *R10,R11
	   B	*R11
*// RLEDEC
  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...