Jump to content

Sheddy

Members
  • Posts

    838
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Sheddy

  1. Like the song, Sack. Maybe could do with a bit more of a Latin rhythm though? - Way better than I could do though. What's your tracker of choice on the Atari? RMT?
  2. reminds me of my favourite John Cage piece - 4' 33" not knocking the tune - which has some OK sounding harmonies - just that ; - ) causes all kinds of trouble with unzipping/showing up in the emulator
  3. reminds me of my favourite John Cage piece - 4' 33"
  4. I wonder what kind of compression this one uses.Simple RLE or something more advanced ? And what about this "XIP" packer ? The program seems to be for the C64 , but is there something similar for the ATARI ? Because I need a packer for an 1Kbyte game for the ATARI. Thimo With just 1K to compress I'd be very surprised if you'll get much compression worth having - it's all about data redundancy and patterns of data, and unless you're very sloppy with your data or code, there shouldn't be too much of that in just 1K. Don't forget you have to get better than 10% off even with the 128b unpack prog to make it worthwhile. You'd really be better off thinking of the most efficient ways to represent your data (IMO). That said, of course it's worth trying the packers to see if they do help though
  5. Much more like traditional western music harmonies than some of your other interesting experiments emkay ...but unfortunately, still not all the voices are in tune with each other. that is going to be a serious problem for "music" rather than just soundfx if the voices can't be tuned more finely , although it is great to hear Pokey doing these different kind of sounds.
  6. Great work Nice to see Graph2Font pics and less chunky mode 9/10/11 graphics - they're a bit of a cliche, even though we're stuck with them for getting lots and lots of colour
  7. Nice to know I'm not alone in creating really weird bug puzzles to try and figure out! It always amazes me what the cause of some of these bugs turn out to be. You're making good progress. In case you don't already know - Sorry to say there is some kind of problem it running when the emulator is running in NTSC(Atari800WinPLus 4.0 beta3)
  8. Thanks Alex H, I goofed on that 2nd adc #1 - should be adc #0 like yours.
  9. oops -128 =11111111 10000000 -0.5
  10. The way you're moving the puck should work fine with + and - You have to be a bit careful on your 2's complements though: your code whilst pretty neat by saving a couple of bytes, doesn't deal with any carry generated by the low byte, which means that when puck_h=0 and negated, the high byte will be out by 1. Not sure, but depending how accurate you want things, that might not be a major issue? I'm sure someone else can clarify that though. This code for 16 bit 2's complement should work ok though: clc lda puck_h eor #$ff adc #1 sta puck_h lda puck_h+1 eor #$ff adc #1 sta puck_h+1 -128=11111111 01111111 when you're testing the -128 don't forget that that high byte must be 255 not 0, as well as the low byte being set to 127. hopefully the darn puck will move the other way then
  11. I'm looking forward to analmux's game(s?) too!
  12. on the homebrew comment, my only point was that if a demo comes out only a few months or so before the game is finished, everyone is happier all round. I just feel in retrospect that it is worth holding back until you know you're ready for sure. I misjudged how long it would take me to finish the game - but I'm glad people have enjoyed the demo. It is still my intention to finish the full game, and the status of "resting" isn't strictly true anymore thanks all for the encouragement
  13. Cool. I still haven't got round to using mine yet, so let us know how you get on!
  14. The sprites and background tiles do exist in the game. If you notice, there are only really 5 PF colours used. and the Player overlays on BUB and BOB. I have recoloured the items to fit the scheme. The cake for instance used the pinks rather than the original arcade spongecake with it orange and creme look. The level colour schemes and the related enemies and items are currently being worked out so that the actual game logic is next. I've got a long way to go yet! I really didn't want to announce the project until I had a working preview to post or a least some of the early stuff as a running preview. Regards.. Oh yeah, I see now! Looks very effective by using the players as overlays. Good Luck with everything!
  15. Nice! Is that level 1 screen shot a mockup or actual in-game? - very colourful!
  16. Sorry for your frustrations, but I'd rather not go down the route of releasing a partial game. If I did have to give up on the game I will release everything to the community so interested parties can have a look or even continue it. But until then or when the game is ready, don't expect to hear too much...I'm embarassed about how long things have taken, and I'll be hiding in the corner! (Note to new homebrew developer's - try not to announce anything until you've nearly finished, or make sure you know exactly what you're doing!)
  17. Did finally get it working, for anyone trying this in future - this also applies to any switchable cart, not just megacart: the normal reset trap can work, but GINTLK ($03fa) must also be correct. on the XL/XE as Bry said, TRIG3 is used to indicate the presence of a cart (0 for no cart, 1 for a cart) the value is copied into GINTLK on coldstart. this gets tested on warmstart (pressing reset). If it doesn't match the value in TRIG3 the system will coldstart - avoiding any reset trapping put in. Switching the cart off is equivalent to removing the cart, so when the RAM under a cart is being used GINTLK should be set to 0 for any warmstart reset trapping to work. Another thing that threw me up was using the $0200-$03ff area of memory for my own code and variables. During a warmstart the OS won't re-initialize itself properly if (at least some of) those locations are changed, and that will cause a coldstart to be performed. NB doing a google search on GINTLK brings up more info
  18. well it's not a 3D game but it is a favourite of many people I am currently working on bringing this to the A8. This post has prompted me to announce it early.. watch this space. Yeah, Stuntcar Racer would be nice too. Wrathchild, you been playing with C64 games again? I'm guessing there'd be enough time to just draw the engine on top every frame and still be able to run at a similar speed to the C64. players and missiles could help out a fair bit too.
  19. Oh dear... it's not a very good test program. the init address is not even pointing into the cart. I don't know why it even does anything...
  20. thanks Bry, I tried messing with those vectors too, but no joy. I had a quick look at what the OS does, but I don't have a good handle on it at all! I thought it might be something to do with the zero page also, so I put together something simple to try and figure things out. Anything obvious wrong anyone can spot? This just puts some colours into the background. It gets copied from the cart to ram when it starts up. the code is then run from ram. the code disables the cart, attempts to set the reset vector to itself, and then just does some background colour changing. On reset it should go back to running itself again. 00:80 A2 00 ldx #0 02:80 BD 0E 80 lda trap_reset+$4000,x 05:80 9D 00 40 sta $4000,x 08:80 CA dex 09:80 D0 F7 bne ?1 0B:80 4C 00 40 jmp $4000 0E:80 A9 80 lda #128 10:80 8D 00 D5 sta $d500 13:80 A9 0E lda #<trap_reset 15:80 85 0C sta $0c 17:80 85 0A sta $0a 19:80 85 02 sta $02 1B:80 A9 40 lda #>trap_reset 1D:80 85 0D sta $0d 1F:80 85 0B sta $0b 21:80 85 03 sta $03 23:80 A9 00 lda #0 25:80 8D 44 02 sta $244 28:80 A9 01 lda #1 2A:80 85 09 sta $9 2C:80 AD 0A D2 lda 53770 2F:80 8D 1A D0 sta 53274 32:80 4C 2C 40 jmp loop FA:BF 00 .byte <setup FB:BF 40 .byte >setup FC:BF 00 .byte 0 FD:BF 00 .byte 0 FE:BF 00 .byte <setup FF:BF 40 .byte >setup Equates: Symbol table: LOOP: 402c SETUP: 4000 TRAP_RESET: 400e
  21. Bit of an unusual scenario I know, but I'm having trouble trapping the reset key when a megacart is switched off to use the ram under it. No problem when a rom bank is switched in of course, it starts by running from the address in $bffe of the rom The normal trick of disk games of putting a 0 (disable reboot) into COLST($244), and the address of the routine you want to run when reset is pressed into $0c and $0d, doesn't seem to work when the megacart is in but switched off- COLDST is being ignored and a reboot is always done. So, is this the correct way of doing things when there is a switchable cart in? Anyone know any games that use switchable megacart that maybe I can peek at? Or do I need to move to another cart format like XEGS that always leaves some ROM mapped in? (Hate to lose the ram though!) I haven't been able to test on a real machine, but am using AtariWinPLus 4.0 beta3 any insights appreciated
  22. Just wanted to add my compliments to the chef - nice job Kenfused I'm now thoroughly addicted to this game.
  23. Encounter does have a "depth map". So the collisions are not done by HW-collision dectection, they are done by software. That is the difference to all other "3D" action games on the A8. When running backwards against a pillar you don't see it. When rotating the vehicle, the pillar is positional always at the right "distance" and "size". The "shoots" are reflected always in the correct degree (impact & reflect). And when moving, you have to check the distance to the enemy and correct the fireing angle. This game is unique on the A8 and technically even more better than the Lucasfilm 3D-Engines. oops - I meant to say Encounter is much more impressive than Dimension X IMO. But the edits are not working today - lots of spelling mistakes etc! the lucasfilm games all had a proper depth-map - eg firing in fractalus took longer to get to a target the further away you were - and the mountain movement as you bank and turn is very impressive. agree the enemies on eidolon are not scaled based on distance or for firing at - but the fireballs and cave is again very impressive and accurate - guess they ran out of memory.
  24. Belonging to the posting-counter? Now one less It's graphics 7 (antic d). The only overlay is in the "aiming square cursor". Encounter - one of all time Atari faves - first time I saw it I just thought WOW!, gotta buy this game! Much more impressive that Dimension X IMO. I always thought at least some of the clouds could be PM graphics - they look the right kind of blocky (streched across) - that would seem a good use of them for this game - never checked though I agree with Emkay and analmux that Antic 5 is certainly an interesting possiblity for a semi-3d Wolf style engine. But think there would be some pretty complex issues for the engine to handle if PM underlays for background/walls etc. especially them not being able to be full width of screen. Think that's probably why people steered away from that idea. Better off using them for enemies or players weapons (like normal games )? Maybe it could be made to work though. Also there'd have to be a fair amount of characters left over for redefining the enemies if they were Antic 5 characters (how big the enemy is at closest range). and if you want more than 1 enemy on screen at once that multiplies it up and complicates things. Still, it'd be nice if somebody puts something together to try and outdo Mood (which is still pretty darn impressive for an 8-bit machine). [/u][/i]
×
×
  • Create New...