Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

Community Reputation

682 Excellent

About SmittyB

  • Rank
  • Birthday 10/06/1992

Profile Information

  • Gender

Recent Profile Visitors

7,258 profile views
  1. Thanks for the offer, but as it is I'm having to shuffle the graphics around for the enemies I do have. With palette swapping and reusing graphics I think I've got an adequate variety though of course it's regrettable that I couldn't add more. The reason it's been a few months since my last update is because I've been working on and off to bring things up to a point where I can release a sizeable demo for people to try out and play test while I work on finishing things. I'm not there yet but there's a lot more polish compared to my last posted build including but not limited to: A credits screen A special thanks screen An enemy viewer I intend to make unlockable after completing the game The completed pseudo 3d voxel map on the title screen A redone title theme Text screens for the story when starting a new game and finishing More particle effects Player projectiles including a fireball that can ignite unlit torches and lights up the map slightly while it's in flight Better level mechanisms including a portcullis that can be raised and lowered with switches in combination with other mechanisms
  2. As I had a lot of trouble trying to understand keypads I've copied the code I use below in case it helps you or anyone else in the future. It's based on code I found posted in the 2600 forums back in 2012 by alex_79 so I can't take credit for it. It reads 1 button at a time and if multiple are pressed it will return the lower-rightmost. It's possible to expand this to read 3 keys simultaneously as long as each is in a different column due to hardware limitations of the keypad circuitry. rem ------------------------ rem Read Keypad - Credit to alex_79 rem ------------------------ rem +++++++++++++ rem + 1 + 2 + 3 + rem +++++++++++++ rem + 4 + 5 + 6 + rem +++++++++++++ rem + 7 + 8 + 9 + rem +++++++++++++ rem +10 +11 +12 + rem +++++++++++++ readKeypad rem disable 2-button mode on 2nd joy port... SWCHB=$ff:CTLSWB=$04:SWCHB=$00 rem SWACNT - 0 = Input, 1 = Output asm ;Set pins to output Right=#$0F, Left=#$F0 lda #$0F ;0F sta SWACNT keypadReadkeypad lda #$0F ;Right=#$0F, Left=#$F0 ldx #12 ;12 clc keypadNextRow ror sta SWCHA ldy #255 ;150 loops minimum, more delay = more reliable results keypadWait ;5*150 = 750 cycles (418us) dey ;2 cycles bne keypadWait ;3 bit INPT5 ;Right=INPT5 ;Left=INPT4 bpl keypadKeypressed dex bit INPT3 ;Right=INPT3 ;Left=INPT1 bpl keypadKeypressed dex bit INPT2 ;Right=INPT2 ;Left=INPT0 bpl keypadKeypressed dex bne keypadNextRow keypadKeypressed stx keypadCurrentKey ;Store result for later reading ;Reset SWACNT for joysticks (Set all pins to inputs) lda #$00 sta SWACNT end return
  3. I think you should just be able to change CHARBASE to whatever the high byte is for the starting address of your tiles in RAM. You would need extra RAM on the cartridge as it would take 4k for a 16 high zone (16 lines * 256 bytes per page) to store everything.
  4. If you did use characters I don't think anyone would mind a bit of clashing, a lot of good C64 shooters used the tiled backgrounds to fake a huge number of shots on screen and nobody cared as long as the gameplay was good. I've made a quick mockup (borrowing the C64 graphics for everything but the laser) of how I always thought I'd achieve a similar effect. There are several laser objects, eight at its peak length, with each subsequent one starting on a different frame of animation of the laser shrinking. You get subtly different effects depending on which side the laser shrinks from. Adding a colour-cycle effect just adds to it. You could adjust how many objects make up the laser and the size / frames of the animation to make it fit what you need. For some reason my editor saves GIF animations slower than they should be, but it looks better at full speed.
  5. SmittyB


    I'm actually tempted to one of these to see how it would perform in a Mateos cart even though I already have a POKEY for it. Something else to consider is the moral aspect of this. Personally I'll never feel comfortable idea with the idea of dismantling Ballblazer and Commando cartridges (though I know it can be reversed if done properly) so a renewable alternative is very appealing to me regardless of the price.
  6. I've never used the indirect arrays in 7800BASIC but I do that using assembly in my game (with thanks to RevEng for helping me with that). This takes the contents of my 'checkMapTemp8' variable and uses it as an index into my list of pointers which are stored as two separate lists, one for the high byte of the address and one for the low byte of the address. Each of my pointers actually points to the start of a 256 byte list and I use my 'titleScreenFloorOffsetTemp' variable as a second index into that list, so in the end I'm choosing a list, and then choosing a byte in that list which then gets stored in temp3. I've added some extra comments to hopefully make it clearer what's happening if you're not familiar with assembly. asm ldx checkMapTemp8 ;load the value to use as an index lda voxelColourMapLowByte,x ;grab the low byte of the pointer sta temp7 ;store it somewhere in memory lda voxelColourMapHighByte,x ;grab the high byte of the pointer sta temp8 ;store it in the next byte of memory ldy titleScreenFloorOffsetTemp ;load the index into the chosen list lda (temp7),y ;load the chosen byte in the chosen list sta temp3 ;store the result in temp3 jmp skipVoxelColourMapList ;jump over the data voxelColourMapLowByte ;List of low bytes (#< will give you the low byte of an address) .byte #<ColourData0 ;0 .byte #<ColourData1 ;1 .byte #<ColourData2 ;0 .byte #<ColourData3 ;1 voxelColourMapHighByte ;List of high bytes (#> will give you the high byte of an address) .byte #>ColourData0 ;0 .byte #>ColourData1 ;1 .byte #>ColourData2 ;0 .byte #>ColourData3 ;1 skipVoxelColourMapList end
  7. You can change which characters represent which tiles using alphachars. Starting at 0 each character will represent a tile from the start of the character set. Personally I like to start with 0-9 A-Z so that the first 16 represent their own value in hex. If you're not writing a lot of text you can probably get away with a limited number of text characters. There aren't many q's and z's in 'new high score' or 'extra life'.
  8. When you change character set it tells the 7800 where the start of your first tile is, then when it draws the tilemap it takes that location and skips ahead a number of bytes to get the tile you want drawn to the screen. As the index of each tile is stored in a single byte you can only have 256 bytes of tiles in use at a time. If your text is always vertically separated from the main tiles then you can look into changing the character set partway down the screen. In the 7800BASIC samples folder there should be a split mode demo that shows how to set up a topscreen routine to wait a number of lines using WSYNC and then change the screen. Also look into how you're using your tiles. Do you really need 2 sets of fonts or can you make do with just 1? If you're using 160B mode then each byte covers 2 (wide) pixels which means if you've cut up your graphics into 4*8 tiles you might have a lot of empty space you can work with, or you could shrink your tiles by 2 pixels and free up some space that way.
  9. If you're already drawing multiple sprites to create a large object then a banner would be a more efficient way of drawing as it would cut out some of the overhead, otherwise banners would have an impact on performance just because there's more to calculate and draw. Don't worry about performance too much, if things start to slow down there's usually something you can tweak in your code to speed it up again providing you're not trying to draw tens of objects to the screen.
  10. You shouldn't have issues using plotmap to draw from a single tile map in RAM. What you need to limit are horizontal changes in palette which would be where a new object would need to be drawn. You don't need to worry about vertical pallete changes as a new object would be drawn for each zone anyway. You could easily build in a limitation saying that groups of 4 or so blocks use the same palette. You could also look at how effectively you're using the 3 colours on a given palette. Are they just different shades of basically the same colour? Could you use dithering to fake extra colours?
  11. As 7800BASIC compiles to assembly which is then assembled into the final ROM you can write something in 7800BASIC and then see what the assembly equivalent is. If you use banners rather then sprites you can have things taller than one zone. As far as the 7800 is concerned they're the same thing but 7800BASIC makes a distinction between the two because they can be optimised in different ways, for example a sprite will only ever cover 1 or 2 zones and where the graphics are loaded from doesn't have to be changed while setting up the display list.
  12. Plotmapfile works by breaking up horizontal palette changes into different objects, effectively it's a shortcut to using a lot of plotchar commands. If you want multiple pallettes on the same line you'll need to break up the map into multiple objects as well. You could look into 160B mode which gives you 12 colours to work with but you might run into the data limitations again.
  13. Looks good, I'd certainly play a full game looking like that. I do like how the colour flashes back in after scrolling, not sure if it would get annoying after a while but it certainly looks good.
  14. Am I understanding correctly that you're drawing a large tile map for the border, and then another in the middle of that map for the blocks? If so then MARIA is almost certainly running out of time to read all that data before it has to draw to the screen, and I imagine using 8 line zones wouldn't help with that either. You would be better off using a map for the top and bottom borders, then using a lot of plotsprite commands to add the sides. You could use a map that's tall and thin for the sides which would be the easy option, but sprites down the sides would be more efficient in terms of the amount of data MARIA has to read.
  15. Not a problem, before a couple of years ago I was clueless on this subject. When I said the zones can't move I should have said the zones will always start immediately after the previous zone. By shrinking the uppermost zone the others will move up to fill the gap. By shrinking the uppermost zone and expanding the lowermost you can shift everything up enough that on the next frame you put everything back and then change which tiles are drawn in the manner you're doing now. Shrinking the lowermost zone etc will let you scroll down.
  • Create New...