Jump to content

CabaretVoltaire

Members
  • Content Count

    43
  • Joined

  • Last visited

Community Reputation

0 Neutral

About CabaretVoltaire

  • Rank
    Space Invader

Recent Profile Visitors

4,520 profile views
  1. Yeeeaaars ago I did a bit of Virtual Boy programming but lost interest because I didn't have any way of playing my stuff on the real thing and emulators don't do the system justice at all. I'm really excited about this Richard, are you going to be selling these to UK folks? It looks like the Vr32 guys are in Germany and I know I would prefer getting one from within the UK. Anyway it looks really cool and I love my VecFlash.
  2. Is there going to be a PAL version of the Minigame Multicart? Or does the NTSC version work ok on PAL consoles?
  3. You couldn't give them away. Gundam, Virtual Lab, Space Invaders and Virtual Bowling (not Nesters Funky Bowling!) sell for crazy amounts though. I don't think they are as rare as people would like us to think though as they are almost always available and always new/sealed.
  4. I'm looking for a Supercharger or some other inexpensive dev solution (if one exists). As I just want it to test my own code I am not bothered about condition, original packaging, bundled games, etc. I am not too bothered about having a modded one as I'll be making sure that my game is compatible with unmodded Superchargers so that everyone can "enjoy" it. A modded one would be nice but I'm not really bothered enough about it to pay a premium. So... If you have a Supercharger you want to sell please let me know, the only thing I am really worried about is whether it works or not
  5. Ooops.. I've actually started a very similar project for the 2600 as my first game. "Atari Misfit Melee" A sort of platform 1 on 1 kind of like the Wonderswan One Piece or Digimon fighting games with Atari misfits. Characters will include a constantly flickering pacman ghost, Custer, Donkey "Wrong".. For special moves the Beat 'em and eat 'em guy will help Custer out.. ET will push you don't a pit. etc.. I've not done any of the characters yet, just finishing up the fighting system
  6. Does this apply to Motorodeo and Ikari Warriors? If so then the rating of 10 is fine. If not then either their ratings should be changed or the rarity scale should be changed. Simple.
  7. Is it easier to get a new sealed copy of Combat or a new sealed copy of Ikari Warriors / Motorodeo?
  8. I was writing to WSYNC at the end of the subroutine.. sta WSYNC rts and then writing to HMOVE after both subroutine calls. I've changed it so that I do both writes after the subroutine calls and it works, thanks.
  9. I cannot get these subroutines to work for more than one sprite. I am doing: sta HMCLR ldx #0 ;-RESP0, HMP0 lda SpriteX jsr PositionSprite ldx #1 ;-RESP1, HMP1 lda SpriteX jsr PositionSprite So both sprites should have the same horizontal position. The first sprite (doesn't matter which one I position first) will be positioned 100% fine.. The second one will be positioned roughly ok but the HMPx setting seems to be wrong as it jitters around whilst moving horizontally..
  10. Thanks, I'll have a look for Star Fire source code. I've managed to write a sub routine to do what I want but it needs 27 bytes of RAM (+ 1 byte per sprite to note which sector it is in) and has a bug where if you have more than 2 sprites in a sector (so flickering is on) and then one of them moves out (so flickering is off) GRP1 and GRP0 will both draw the same sprite for one frame. Although it's not that noticable and is just like an extra frame of flickering I guess.. I'm not really happy about using that much RAM for just sprites as I'm sure I'll need more than what's left over to add game logic, sound, etc..
  11. I am trying to design a kernel where I can have x amount of sprites that can appear anywhere on the screen. What I want to do is split the screen into rows and then dynamically assign software sprites (player/enemy/item/whatever) to hardware sprites (GRP0,GRP1) depending on how many software sprites appear in a row. If 1 sprite appears in a row then I just use GRP0 to display it. If 2 sprites appear in the row then I would use GRP0 and GRP1 to display them. If more than 2 sprites are in a row then I would flicker between them.. For example if 4 sprites are in the same row then I would do: 1st frame: GRP0 = sprite1 GRP1 = sprite2 (GRP0 = GRP1, GRP1 = next sprite) 2nd frame GRP0 = sprite2 GRP1 = sprite3 3rd frame GRP0 = sprite3 GRP1 = sprite4 (GRP0 = GRP1, GRP1 = first sprite) 4th frame GRP0 = sprite4 GRP1 = sprite1 5th frame GRP0 = sprite1 GRP1 = sprite2 ...for each row I have a kernel that splits the screen into sectors/rows of 24 scanlines, and checks if a sector has a sprite in it. If the sector contains no sprite then the next 24 scanlines are free to do whatever. If the sector does contain a sprite then the usual checking takes place. So what I want to do is extend what I have to draw 2 sprites per sector (which is simple enough), and have some code during vblank or overscan (or during empy sectors!) that does this sorting. I just can't quite get my head around how to implement this idea assembly.. I've noticed that a few games must use a similar system (dig dug for example) so was hoping that someone here has coded something like this before and could give a few pointers. One problem is RAM. I figure that I'd need 2 "arrays", one byte per sector to hold what GRP0 should display in each sector and what GRP1 should display per sector. Then I would need another array to keep track of what the last item would be (how I would know when to loop around back to "sprite1" in the above example). It seems like a lot of RAM really.. Then the actual code to do it all might be a bit heavy too.. Just how do games like Dig Dug do this?? (trying to code for the VCS makes you really appreciate the coding behind these games, even though they do often look really primitive like Dig Dug does).
  12. What about something like this: You split the screen up into sectors (say 8 rows of 24 scanlines). Then have a variable "SECTOR_TBL" where each bit is referring to one of these sectors. For example if SECTOR_TBL is set to #%100000001 then there is a sprite in the top sector and in the bottom sector. The kernel could look something like: lda #128 ;sector sta SECTOR; MainDisplayLoop lda SECTOR and SECTOR_TBL ;check if bit is set beq SectorContainsSprites SectorHasNoSprites ;do whatever you like for 24 scanlines ;decrement some counter bne SectorHasNoSprites jmp EndOfDisplayLoop SectorContainsSprites ;check if sprites are on this scanline ;decrement some counter bne SectorContainsSprites EndOfDisplayLoop lsr SECTOR bne MainDisplayLoop I'm not sure about cheaply setting the SECTOR_TBL variable. Once it is initially set I think that it would be easy to check if a sprite has left the sector it is in. But I think initially setting it all up would be expensive. I'm pretty sure that someone has atleast considered a similar system before so thought I'd ask if it's worth pursuing. It looks good to me as it would leave whole areas of the screen free to process other things.. [edit] Fudged up a little crappy kernel that displays a sprite using this method. It's very dirty and doesn't display quite right (bottom scanline is cut off??) as I'm very much a beginner. My implentation is awful but I think the idea is fine. What do the experts think? The red area is where any sprite checking is taking place. In the grey areas I'm doing nothing at all really. sectors.zip
  13. I hate ebay (well the sellers really, there's not much wrong with the service) but it's my only choice for classic games. I haven't seen anything in charity shops in years apart from a few CDI and Megadrive games which were stupidly overpriced. The era of finding retro stuff at car boot sales seems to be over, whilst I might occasionally see something interesting people seem to think that retro stuff is really really valuable these days (some guy wanted £50 for a 2600jr and a few common games like Pacman, or £20 for a loose nes with Mario/Duckhunt).. I usually see about 20 playstations and absolutely nothing interesting when I go to a carboot. Gamestation do some retro stuff but have really odd pricing.. Normally prices are much higher than the usual ebay prices, for example I've seen a loose Vectrex for £150 (I paid £50 for one with a bunch of games a few months ago on ebay) and a loose Virtual Boy for £250 (LOL). I did get a Microvision from them very cheaply though There's also no websites (that I know of) that sell classic games cheaply in the UK. Everyone has the attitude of "HEY I KNOW THAT THEY SELL FOR £100 ON EBAY!!", whilst in reality their item might fetch £10. Or there's non-ebay businesses selling retro stuff who don't have a clue. I used to think Telegames were bad but I've seen "retro specialist" sites trying to sell 2600 Pac Man for £15, urgh.. Maybe ebay ruined the market but right now it's the only place I know where a 99p cart doesn't cost £5. I agree that it isn't a nice place but I don't see any other choice really.. I would quite happily stop using it but only if the sellers did also, but they wont because they can usually get more money selling an item on ebay than they would selling it directly on these forums for example.
  14. I have some code that I'd like to turn into a subroutine but can't work out how to do something similar to C pointers to make this possible.. My code at the minute alters the contents of some RAM addresses but is repeated several times for different RAM addresses.. I'd like to do something like ldx [address of variable] jsr MySubRoutine Where the subroutine will can do something like: stx temp and then load/read from the original variable with ld? #temp st? #temp right? Thanks!
  15. I'm sorry for replying to such an old thread and hope that noone minds. I am starting to follow these lessons now, as well as the Stella guide, and just want to make sure I am understanding this correctly: At the start of a frame (or at the start of overscan period?) you have to set the VBLANK register to 2 which turns off the TV beam.. I think it would be best to turn off the beam at the start of overscan.. Which would mean my very first frame would have the beam turned on during vsync/vblank.. Is that ok to do? I notice in the example kernel it is done like this but just wanted to make sure... ..and then write 2 to VSYNC to say that we are vsync period. VSYNC period is for 3 scanlines so I should write anything(?) to WSYNC 3 times. Can I do anything else during this time, is it possible to do: ;some code sta WSYNC ;some more code sta WSYNC ;even more code sta WSYNC aslong as the code, including the sta WSYNC, doesn't exceed 76 cycles? Or is it possible to skip the WSYNCs altogether as long as I have 76*3 cycles of code or code + a sta WSYNC that comes in at less than 76*3 cycles? Then I should set VSYNC to 0 to say that we are no longer in the vsync period. I then have 37 scanlines of vertical blank.. So essentially 37 "sta WSYNCs", again is it ok to put code here.. Now I should be drawing stuff right? So I have my 192 scanlines before overscan.. So at the start of overscan I think I have to set VBLANK to 2, and then I have 30 lines which I can treat in pretty much the same way as VBLANK right? I am sorry if this seems stupid but I want to make sure that I understand all of this properly before moving on!
×
×
  • Create New...