WIP : @!#?@!

Talk about programming of homebrew games only.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Wed Dec 10, 2014 10:04 pm

Mobsie wrote:thank you very much, looks great. Will go now in the source code. I send you later my VBL based sprite routine with also the SAT rotate function to avoid 5th sprite flicker. Maybe help you.
Look forward to it! Sprites will be next to work out!

In the meantime, here's the latest with all custom characters defined.

If you have a Salora Manager, Laser 2001 or CSL, you can check out the colour cycling discs and flashing arrows on a real machine!
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Post by MADrigal » Wed Dec 10, 2014 10:07 pm

Wow that looks impressive!! Just like the arcade game! :-)

Great!
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Thu Dec 11, 2014 1:56 pm

MADrigal wrote:Wow that looks impressive!! Just like the arcade game! :-)
The graphics are actually from the SG-1000 and TI99/4a.
To me, the TI99/4a graphics, as they are in Graphics Mode 1, are more suited to our slow 6502 - and the general concensus is that the TI99/4a looks best of the TMS99xx variants.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Fri Dec 12, 2014 3:08 pm

Damnz! - no sprites yet and already I have exceeded the 4K ROM boundary!

My initial thought was to use good old pucrunch and keep going.

Then my mind wandered, as it often does, to thoughts of is there a better compression scheme?

The biggest problem is lack of memory, so that ruled out most dictionary based compression schemes.

In the end I have come up with a fairly easy to implement compressor, as there's little computation and not too much bit crunching.

Note that this is a prototype only

I came up with the idea of having three stage, basic algorithm compression, and for a graphics mode 1 character set, the results are pretty cool.

The three stages are Move-To-Front, ZeroRunning and finally Elias gamma coding.

With respect to Q*Bert, I have called this creation - WTF! :)

These are the results for the 2048 byte mainpat.bin file.
  • 7Zip - 452 bytes
  • WinZip - 486 bytes
  • PuCrunch - 621 bytes
  • WTF! - 380 bytes
Next step - is writing the 6502 decompressor.
User avatar
Mobsie
Posts: 708
Joined: Fri Jun 13, 2008 10:38 am
Location: Weinheim, Germany

Re: WIP : @!#?@!

Post by Mobsie » Fri Dec 12, 2014 6:37 pm

WOW!
Thats great, i will be happy to use in my coming Escape game and the Shamus clone because the maps and the multicolor take a lot space.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Sun Dec 14, 2014 7:28 pm

Ok - working 6502 decompressor!

Currently v0.4 uses 432 code bytes - which is not so bad.
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Sun Dec 14, 2014 11:19 pm

WTF! works really well on small data sets.

Attached is the latest BIN which contains > 4K graphics, sprites and music!
You do not have the required permissions to view the files attached to this post.
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: WIP : @!#?@!

Post by MADrigal » Sun Dec 14, 2014 11:42 pm

Wow it works great!!!

A part from the graphics and sound, that are both perfect, what is your approach to the actual game routines (movement, score, AI, etc.)?

Are you willing to code everything from scratch, or do you feel that a "conversion" of the original TI99/Z80 code into 6502 code would be feasible?

Or do you believe that an approach through the C64 version (written in 6502 ASM) would be easier, and/or interesting?
User avatar
@username@
Posts: 320
Joined: Tue Oct 22, 2013 6:59 pm
Location: Scotland

Re: WIP : @!#?@!

Post by @username@ » Mon Dec 15, 2014 12:46 am

MADrigal wrote:Wow it works great!!!
Did you run it on real hardware? I'm never 100% sure of the VDP timings.
MADrigal wrote:A part from the graphics and sound, that are both perfect, what is your approach to the actual game routines (movement, score, AI, etc.)?
The logic of the game is very well described here http://www.atarimagazines.com/cva/v1n2/qbert.php, so scoring etc will be the same as the table at the end of the article.
The modes of attraction, or not, are also described in good detail.
MADrigal wrote:Are you willing to code everything from scratch, or do you feel that a "conversion" of the original TI99/Z80 code into 6502 code would be feasible?
I think we will end up with a hybrid. Parts which make sense to me will be coded, then verified against the other versions. This helps when I'm unsure, or they have a better solution.
An example of this is with the main Q*Bert sprite. Logically, you would change the sprite number in the attribute table when Q*Bert changes direction.
However, this is not how the original developers coded it.
They decided to just change the actual sprite data. While this may seem more time consuming, moving 32 bytes instead of 1, it does make managing the game play easier - as you are only tracking a single virtual Q*Bert's position.
MADrigal wrote:Or do you believe that an approach through the C64 version (written in 6502 ASM) would be easier, and/or interesting?
Hmm. I prefer to stick with the SG1000/TI99/Coleco, mostly because the video and sound are the same - so no problem working out what's actually going on :)
User avatar
MADrigal
Site Admin
Posts: 1189
Joined: Sun Sep 15, 2013 1:00 pm
Contact:

Re: WIP : @!#?@!

Post by MADrigal » Mon Dec 15, 2014 1:15 am

@username@ wrote:Did you run it on real hardware? I'm never 100% sure of the VDP timings.
Unfortunately not. I have no hardware here in Canberra. I tested it on emulator only.
@username@ wrote:The logic of the game is very well described here http://www.atarimagazines.com/cva/v1n2/qbert.php, so scoring etc will be the same as the table at the end of the article.
The modes of attraction, or not, are also described in good detail.
Wow that's a saucerful of information and hints!
@username@ wrote:An example of this is with the main Q*Bert sprite. Logically, you would change the sprite number in the attribute table when Q*Bert changes direction.
However, this is not how the original developers coded it.
They decided to just change the actual sprite data. While this may seem more time consuming, moving 32 bytes instead of 1, it does make managing the game play easier - as you are only tracking a single virtual Q*Bert's position.
What you write makes perfect sense. I'd go with the sprite data change method. I suppose that's the standard method in 8-bit computer games. Also, moving 32 bytes inbetween two consequent VDP-cycles shouldn't be a big issue on a 2MHz cpu.
@username@ wrote:Hmm. I prefer to stick with the SG1000/TI99/Coleco, mostly because the video and sound are the same - so no problem working out what's actually going on :)
Will it be easy to "translate" the "jumping" routines from Z80 to 6502? I suppose there should be no big difference between the two as it's just math calculation, should use more or less the same ASM commands.

Thanks for the information. :)
Post Reply