|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2 |
Author | Message |
---|---|
|
Posted: Tue Oct 20, 2015 9:24 pm |
OK, I guess I'll make this a 32k game then. I didn't know any better when I started this game. Anyway, this should be a learning exercise, and I have been learning a lot about Game Gear coding. | |
|
Posted: Tue Oct 20, 2015 10:07 pm |
I don't see the logic. | |
|
Posted: Wed Oct 21, 2015 2:59 am |
I tried dividing the code into 4 banks. It didn't work at all.
.memorymap defaultslot 0 slotsize $4000 slot 0 $0000 slot 1 $4000 slot 2 $8000 slot 3 $c000 .endme .rombankmap bankstotal 4 banksize $4000 ; 16kb banks 4 .endro The above code should give me 4 banks that are each 16k, but the program is giving me error messages:
the breakdown of the code is: bank 0 - lines 90-1216 bank 1 - lines 1217-2335 bank 2 - lines 2335-2739 bank 3 - lines 2730-2806 (essentially, all the includes) What am I doing wrong? My code is in this link. http://www.atari2600land.com/mrultra/mrultra21a.asm |
|
|
Posted: Wed Oct 21, 2015 3:25 am |
Why can't I have 2 32k banks? It lets me do that. |
|
|
Posted: Wed Oct 21, 2015 7:40 am |
The common mappers have 16KB slots. You only have 48KB of ROM space so that's a sensible division. WLA DX will let you do anything but it won't be compatible with emulators or existing hardware.
The error you get is telling you that something in slot 3 is specifying an origin (.org) at address $4000 but the bank is effectively from 0 to $3fff (in terms of space in the bank, if you use .org) or from $8000 to $bfff (in terms of mapped addresses in slot 2, if you use .orga). Maybe there's something in an included file? Or maybe you need to put origin directives after your bank directives to reset the address, I can't remember if that's required... It looks like your banks won't be very full. When it builds, WLA DX should be able to tell you the unused space in each. I can't check it myself without having all the files... |
|
|
Posted: Wed Oct 21, 2015 6:35 pm |
This game reminds me of a atari 2600 game very simple gameplay. | |
|
Posted: Wed Oct 21, 2015 9:23 pm |
Could it be the PSGLib? That seems to be what it might be, since it uses slot 3. |
|
|
Posted: Thu Oct 22, 2015 8:12 am |
PSGlib expects RAM (not ROM) at slot 3. If you've got RAM at a different slot, change the slot in your PSGlib.inc code. | |
|
Posted: Thu Oct 22, 2015 8:20 am |
The include is in bank 3, slot 2. I really need the full source to figure it out. | |
|
Posted: Thu Oct 22, 2015 9:53 am |
Your use of banks is a bit messed up.
Did you randomly place .bank/slot pairs? For example why do you put bank 1 and bank 2 into slot 1? You're never setting any mapper registers so you will never see bank 2 in slot 1. Also you've placed PSGlib into bank 3 and never page in bank 3 but still you're calling PSGlib functions. While this won't cause trouble in the assembler it will most likely make your game crash. Please remove the line .bank 2 slot 1
because your code won't take more than bank 0 and bank 1 and you're never mapping bank 2 into slot 1 anyways. And as suggested by Maxim always add .org 0
right after your .bank/slot pairs to ensure that the assembler starts at the beginning of the new bank. And also please put .include "filestouse\PSGlib.inc" ; include the library
before .bank 3 slot 2
and turn .bank 3 slot 2
into .bank 2 slot 2
Depending on the size of your data you might need to split the data up (your includes at the end of the file) and put some of it into .bank 3 slot 2
Also I believe most of those .include should be .incbin instead. Or did you store all your tiles/tilemaps in textual format?
|
|
|
Posted: Thu Oct 22, 2015 9:26 pm |
But if I get rid of the bank 3 line, where would it go? | |
|
Posted: Thu Oct 22, 2015 9:45 pm |
I've assembled your code without any include (as I don't have the files) and I've removed all of your .bank/slot directives other than .bank 0 slot 0 so all code goes into bank 0 and then there is still 72.38% free in bank 0. So why do you spread your code over all 4 banks?
There's most likely no need for a bank 3 yet because you still have bank 1 and bank 2 to fill. You could put some assets into bank 1 and others into bank 2. That way you won't need to bother with mapping yet. |
|
|
Posted: Fri Oct 23, 2015 6:35 am |
I put some code in bank 3 because I thought there had to be something in all banks. I did what you suggested and I still get error messages. I guess I'll stick to 32k, and perhaps my next game can be planned better and be 64k if it needs to be. I'll plan it out better. If anyone wants the include files, they're in the link in post #1 of this thread. | |
|
Posted: Fri Oct 23, 2015 4:29 pm |
You can leave banks empty. That's no problem at all.
You will have a very hard time filling 32k with game code alone. Very few games do this. So, normally, there should be no need for paging in code, which is pretty much the only thing that's can be tricky in regards to paging. Most people just use the additional banks to store data, which they access by paging the appropriate bank(s) into slot 2. Speaking of data, all your includes seem to be uncompressed raw data. It's only natural that the files are huge as a result. You really, really want to look into compression if you want to get anywhere in SMS/GG programming. Even one of the less efficient methods (like the popular PS compression) will free up a ton of ROM space. Even simple RLE would be an improvement over raw uncompressed data. |
|
|
Posted: Fri Oct 23, 2015 6:27 pm |
I tried making it a 32k with 2 banks and I couldn't even do that. It kept giving me a whole bunch of MEM_INSERT error messages. | |
|
Posted: Tue Nov 03, 2015 3:33 pm |
The game is finished. I have 3.52% of room left for stuff to change. Let me know what you think.
http://www.atari2600land.com/mrultra/ |
|
|
Posted: Tue Nov 03, 2015 6:28 pm |
Considering this is your first venture into z80 assembly language, the game's actually quite nice. As I said before, it reminds me a lot of that old Intellivision Smurfs game. I also like the simplistic style of the graphics, it's really unique. And the music is nicely done and very humm-able. All in all, Mr. Ultra could use a little more variety, though. Does the game actually scroll or are the chasms created using sprites? Is there some sort of ending? I haven't been able to pass even the first corn enemies in level 3. |
|
|
Posted: Tue Nov 03, 2015 6:37 pm |
The holes are sprites. There is an ending after the 7th level. The trick to getting past the corn is to wait until they come closer, then jump over them and press right when they're closer to the left edge of the screen. Thanks for the compliments. | |
|
Posted: Tue Nov 03, 2015 7:45 pm |
Congrats for completing your first gg-game! I think it turned out pretty well. And you go full circle with graphics, music, multiple levels, etc.
The mr. Ultra sprite reminds me a little of the characters from the Sierra adventure games from back then... I'm amazed how you have worked/added/improved/transformed the code from Racer into this completely different game! |
|
|
Posted: Tue Nov 03, 2015 9:13 pm |
The source code is certainly amazing :) It's basically a bunch of code for everything, not really any data to drive the levels. Clearly it works, but it doesn't seem like it will scale well to a much more complex game.
Can you provide the source graphics? I'd like to have a go at compressing them to show how much space it saves - right now, your 31613 bytes of game are 23552 bytes of graphics data, 2459 bytes of music data, and 5241(ish) bytes of code. By comparison, my "ono" game (the only one I have handy right now) is 5459 bytes of code and 3426 bytes of graphics and lookup tables (not counting the music engine and data as that's a binary blob). Admittedly ono doesn't have a lot of graphics, but then nor does Mr. Ultra... |
|
|
Posted: Tue Nov 03, 2015 9:20 pm |
Here are all the pictures to Mr. Ultra:
http://www.atari2600land.com/mrultra/mrultrapictures.zip |
|
|
Posted: Tue Nov 03, 2015 10:18 pm |
I suggest you start working on your second game taking advantage of what you learnt doing this one. Don't forget ramsections. | |
|
Posted: Wed Nov 04, 2015 6:31 am |
Impressive and in such a short time frame :) | |
|
Posted: Wed Nov 04, 2015 7:45 am |
In a brief play with the code, it was clear that PSGLib's use of ramsections is quite hard to mix with other methods of RAM control. I'm not convinced that RAM sections are useful for Sega 8-bit use as they are intended, i.e. swappable chunks for memory reuse in blocks. As a library, I think PSGLib should try to live with a definition or label as the bootstrap to its memory use, as Mod2PSG2 does, to put less restrictions on the user. |
|
|
Posted: Wed Nov 04, 2015 8:55 am |
On the contrary, I see ramsection as the perfect way to lift the burden of defining each variable at a constant position, with its risk of overlap, and in a more efficient manner. Even if you don't need to swap chunks, using ramsections you can separately declare variables in each of your asm sources and keep things simpler. Finally, I believe libraries (such as PSGlib) should never use memory at a fixed address, both ROM or RAM. | |
|
Posted: Wed Nov 04, 2015 6:48 pm |
I mean to allow the user to define a symbol like PSGLibRAM, which is the first byte used, by whatever means they like and you define all your memory relative to that. Unfortunately ramsections require you to define a suitable memory map with RAM in the correctly numbered slot. I tend to use enums instead due to some stuff not working with ramsections (e.g. defines referencing items). | |
|
Posted: Thu Nov 05, 2015 12:09 am |
Ah this trick! Finished the game, thanks for the fun. |
|
|
Posted: Thu Nov 05, 2015 9:31 am |
I got it, I'll try to add a note and some code to switch away from ramsections if the user wants it... edit: update released. It shows how to use a WLA-DX .enum section instead of a .ramsection |
|
Goto page Previous 1, 2 |