Jump to content

The Southsider

  • entries
    81
  • comments
    767
  • views
    136,529

Juno First Betas

Sign in to follow this  
cd-w

1,591 views

I had a holiday yesterday and was able to spend some time finishing Juno First. I have now posted a beta version in the homebrew forum for general testing.

 

blogentry-6563-1210081166_thumb.png

 

There are quite a few changes since the last version that I posted, namely:

  1. There are now 32 unique waves, and I have made many changes to the previous set of 16. The game actually has 64 waves in total, but the second 32 are the same as the first with a higher speed setting.
  2. The fuel gauge now empties at twice the speed, which means that there is only 45 seconds to complete each wave.
  3. I have finally added the explosion sound effects and an effect at the beginning of each wave.

EDIT: the source code is attached below (binary versions are in the homebrew forum). As usual, let me know of any problems.

 

Chris

Sign in to follow this  


17 Comments


Recommended Comments

Congratulations on reaching Beta, Chris! Regrettably I haven't had much time for testing lately. I haven't even downloaded Cabbage Patch Kids yet!

Share this comment


Link to comment
Congratulations on reaching Beta, Chris! Regrettably I haven't had much time for testing lately. I haven't even downloaded Cabbage Patch Kids yet!

 

Thanks for the message. I was like that last year, which is why Juno First took so long to complete. I hope you get a break soon as I'm really looking forward to seeing Chetiry completed.

 

Chris

Share this comment


Link to comment

Thanks for the encouragement, Chris. Oh yes, I'll get a break this summer. That's the nice thing about working in education. The thing is I'll be busy catching up on all the things I haven't done since September. So the question is, will there be enough time to finish a homebrew along the way?

Share this comment


Link to comment

Doesn't assemble for me. :cool:

d:\_privat\Atari\dev\dasm\Projects\JunoFirst>dasm juno1.asm -f3 -ojuno1.bin
---- $0 bytes left (RAM)
---- $31a bytes left (BANK 1 - MAIN GAME)
---- $116 bytes left (BANK 2 - KERNEL A)
---- $116 bytes left (BANK 3 - KERNEL B)
juno1.asm (2521): error: Unknown Mnemonic '256'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
juno1.asm (2526): error: Unknown Mnemonic 'BINDEX'.
---- $1f6 bytes left (BANK 4 - GAME LOGIC)
---- $30 bytes left (BANK 5 - WAVE DATA)
---- $a bytes left (BANK 6 - SAVEKEY)
---- $606 bytes left (BANK 7 - MUSIC)
---- $119 bytes left (BANK 8 - TITLES)
Unrecoverable error(s) in pass, aborting assembly!

I am using the latest vcs.h, macro.h and DASM files.

 

BTW: If you need help optimizing for some extra space, please let me know.

Share this comment


Link to comment
Doesn't assemble for me. :cool:

 

Not sure why you are having this problem - I am using DASM 2.20.11 and unmodified standard include files. The only difference is that I am using Linux. Perhaps there are some special characters in the source code, or it is getting confused by the carriage returns. I have attached an archive (Juno_First_BETA2.zip) to the top level containing the latest version. This archive contains the .h files that I am using and a version of the source (juno1.asm.dos) that has been run through unix2dos - can you see if this works for you?

 

BTW: If you need help optimizing for some extra space, please let me know.

 

I'm OK for space at the moment thanks to a huge 32K ROM size, but I am desperately short of RAM if you can spot any obvious optimisations?

 

Thanks,

Chris

Share this comment


Link to comment
I have attached an archive (Juno_First_BETA2.zip) to the top level containing the latest version. This archive contains the .h files that I am using and a version of the source (juno1.asm.dos) that has been run through unix2dos - can you see if this works for you?

Works! :cool:

 

I'm OK for space at the moment thanks to a huge 32K ROM size, but I am desperately short of RAM if you can spot any obvious optimisations?

Finding RAM is tougher. I will have a look.

Share this comment


Link to comment
Finding RAM is tougher. I will have a look.

 

I'm glad it assembles for you now. Don't spend too long looking as the game is essentially finished - just if you spot any obvious optimisations. One thing that could use some optimisation is the music player and data. It is currently occupying its own bank (bank 7), but if it could be squeezed in with the title-screen data (in bank 8 ) then I would have space for another colour scheme.

 

Thanks,

Chris

Share this comment


Link to comment

I am far from understanding your code, but I noticed some things. Generally your code looks very good organized (better than a lot of my own code :cool:). But some things could be improved:

1. You are mixing temporary, local variables with permanent, global variables (e.g. INVS). This makes it hard to keep track of RAM usage.

IMO you should define are rather large, global space for temporary variables. Then you can optimize this space for size and get rid of blocking RAM space permanently.

2. While you are at it, I would use the SUBROUTINE keyword of DASM and define local variables locally by preceding them with a '.' (this is possible for lables too).

That brings your code closer to high-level languages and makes it IMO better maintainable.

 

Some subjective, random code style tips:

I am using mixed case for variables and labels, and upper case for constants only. IMO makes the code more readable.

I use the SUBROUTINE keyword wherever I can and define my local variables right at the start of a subroutine.

Local lables and variables allow you to be lazy and reuse names. :(

 

Last not least, for a vertically oriented game, I would try to use more than 192 scanlines for the kernel (NTSC TVs can easily display 200 and more lines). Even if that means using more than 262 scanlines in total.

Share this comment


Link to comment
One thing that could use some optimisation is the music player and data. It is currently occupying its own bank (bank 7), but if it could be squeezed in with the title-screen data (in bank 8 ) then I would have space for another colour scheme.

Music player and data require about 2.5k. But there is just maybe 1k free in bank 8.

 

Hmm... :cool:

Share this comment


Link to comment
Music player and data require about 2.5k. But there is just maybe 1k free in bank 8.

Hmm... :cool:

 

Yes, it's probably not possible, unless some clever encoding of the music data can be found.

 

Chris

Share this comment


Link to comment
Yes, it's probably not possible, unless some clever encoding of the music data can be found.

 

The smallest blocks of the music data are 9 bytes and it's broken down in three levels. That would usually provide a good compression already, compared with totally raw data.

 

Does the music kit allow tweaking of the size of the smallest blocks? Maybe 3 or 6 would produce a better result. I kept that value totally variable in SID2TIA, since you can often gain another 10-15% by finding the "best" granularity. The smaller the blocks get the bigger the overhead in the next level gets, so at a certain point you're losing more than you gain when going to an even smaller block size.

 

I only do 2 levels though, since that makes more sense for smaller songs with few repeating parts. For a larger song with more repeating parts three levels are better.

 

It can also make sense to use different granularities for both voices for optimum ROM usage, unfortunately at the cost of extra position counters in RAM though.

 

So far for the theory. As for getting "real", it'd be best to have the raw data in hands, then you can go and try some things. I wouldn't expect to gain more than 20% during such a process (since it already _is_ patternized), so personally I wouldn't even try to get it from 2.5K down to 1.0K if that is the only goal.

 

BTW: AFAIR did supercat write some pack/unpack code for music somewhere during the creation of Toyshop Trouble. Would be interesting to see wether packing is better than patternizing. I'm pretty certain though that proper patternizing will win in most cases :cool:

Share this comment


Link to comment

Thomas,

 

Thanks for the suggestions. The variables are certainly in a mess at the moment. This happened when I integrated together all of the different parts (high score table, title screen, music, main game). I managed to find a couple of spare bytes to improve the high score table by organising things better. I haven't used the SUBROUTINE keyword before - it sounds very useful - it's probably too late for this project but I'll definitely use it next time.

 

Chris

Share this comment


Link to comment
I am desperately short of RAM if you can spot any obvious optimisations?

I haven't checked whether you've done this already, but you can squeeze a few bits of RAM out of the PC. In fact, supercat described a lot of clever ideas for milking extra RAM out of the Atari during our chess discussion.

Share this comment


Link to comment
I haven't checked whether you've done this already, but you can squeeze a few bits of RAM out of the PC. In fact, supercat described a lot of clever ideas for milking extra RAM out of the Atari during our chess discussion.

 

Thanks for the pointer - there are some good ideas in there that I would never have thought about!

 

Chris

Share this comment


Link to comment
Guest
Add a comment...

×   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...