Jump to content

Sdw

Members
  • Content Count

    86
  • Joined

  • Last visited

Community Reputation

89 Excellent

1 Follower

About Sdw

  • Rank
    Star Raider

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Sweden

Recent Profile Visitors

7,203 profile views
  1. Music was composed as an XM module (with severe restrictions of course) then put through a converter I wrote to output raw data that I can then use to feed the sound registers.
  2. My first demo for this (at least around my part of the world) completely unknown console! https://www.youtube.com/watch?v=ksY7Fm8kS68&feature=youtu.be If you want the binary to run in MAME/MESS - or perhaps on your own Astrocade - it can be found here: http://ag1976.com/files/Genesis_Project-Astrocademo.zip
  3. Thank you all for the positive comments! And carlsson is exactly right regarding the 3F-extension, it's just to force the correct bankswithing scheme.
  4. At the Silly Venture party the theme for the VCS/2600 compo was to celebrate the 40 year anniversary of this fantastic piece of hardware. Together with Mermaid I put together a little entry and sent to the competition: https://www.youtube.com/watch?v=6VDm974mpLU You can get the ROM file here (for PAL only): http://www.pouet.net/prod.php?which=72716
  5. I'm developing some new stuff, and I'm currently experimenting with the Tigervision style bankswitching. When doing a 16kb Tigervision ROM (7 switchable 2kb banks first, the one static 2kb bank at the end) it works fine in Stella as long as I force 3E or 3F in the "Game options". However, on my Harmony cart, no matter if I use the .3e or .3f extension, the ROM does not work properly at all, it doesn't boot. I then padded it up to a 32kb ROM (15 switchable + 1 static) and it works fine in both Stella and on Harmony. Is there some issue with the Harmony and 3F 16KB Tigervision? In theory this bankswithcing scheme could work for any cart size that is a multiple of 2kb, but I guess this is not the case?
  6. As the release of "Spaceman Splorf" draws closer, I've unfortunately had the following report regarding the NTSC version: "I’ve been testing the game on a 6-switch 2600, and it has been just fine. Readying for the show, I was going to use a 4-switch 2600, but for whatever reason, the game loses its vertical hold during game play (not on the main title screen)Have tried this on two 6-swtich units, and it works fine, and two 4-switch units which both have the vertical hold issue (on 3 different TV sets)." As I'm in PAL-land myself and only have a PAL2600Jr, I have no real way to test this. Linecount for the NTSC version is a steady 262. Anyone ran into this issue before? The only thing I can think of that I do that is "non-standard" is that ingame I have a displayable area that is a big bigger than 192 pixels (can't recall the exact count), but on the titlescreen (which apparently is working fine) it is a bit less. Could I be hitting some limit of minimum top/bottom VBLANK area size that is different on the 4-switchers compared to 6-switchers?
  7. The font has been redrawn since the version posted in the video, it looks a bit more like the C64 version now at least...
  8. Yes, enthusi's link will lead to to all the stuff I have done on different platforms. As far as VCS demos, I've done a number of them, but the two "major" ones are: and
  9. As I'm soon to release my first game, reading this topic has made me a bit apprehensive. Even if it's a quite simple game, the plan was to have a cartridge release as well, since, well, it's cool to have your game on physical media. And also for me, the actual making of money on something you have created just for fun is a cool feeling. As it is now, I will probably be looking at a $3 profit per cart sold, and if the game sells 10 copies, that means that one month when I pay my internet bill or something, I can think "well, this was actually paid for by the game!" Now, while the game is written in painfully hand-optimized assembler, it is a rather simplistic concept. We have tried to balance it and make it fun to play, and nice to look at, but it will not have every cool feature that everyone could imagine, and to me that is OK. I have other things I want to do, other demos and games I want to write, spending a year on polishing every detail to absolute perfection would make it "work". For me, creating games is "fun".
  10. Only in RAM. So you will need to have the 2600 powered on until everyone has had their go, or write it down on paper! Unfortunately it is hundreds of lines of seriously ugly code that is not fit for the publics eye! However, one of my main space-eating solutions is that I draw the player like this: lda (PLAYER_GRAPHICS_ZP),y sta GRP0 lda (PLAYER_COLOR_ZP),y sta COLUP0 Y-is the line counter in the kernel. Then I move the player up and down by modifying the ZP-vars. Works great and is very CPU-time efficient, but it means that I must have a buffer that is as high as my player, for both graphics and colors, and then duplicate this if I want more frames of animation! I've actually written quite a few demos for the 2600 before, but this will be my first game. I will probably do more demos, and perhaps there will be more games, but I probably prefer democoding, where the challenge is to create the best looking visuals and any shortcuts can be taken, because you know *exactly* what is going to happen. With games, you have less freedom in the coding.
  11. Oh, forgot to comment on the 4kb question! The game will not be including the graphical intro from the C64, for space reasons. The game will still be an 8kb game though! It might be me that's not a very experienced coder, but writing the display kernel that allowed a player with single-line resolution move freely up and down a screen, and then have horizontal repositioning of the other objects (for asteroids and stars) while maintaining single-line resolution I ended up with quite a lot of duplicating code and large tables, so there's lots of ROM "wasted" on this. For me it was worth it though, to have the best graphical quality.
  12. Thank you all for your comments. As for the suggestions for additions to the game, I understand that the game concept might seem a bit simple as it is, and it might not be for everyone, but the idea is to have a really, really easy to pick up "party" style game, where you get the controller and instantly know what to do! Press the button to go up, release to go down, avoid stuff, try to survive as long as possible to get a high score, and that's it! We had the C64 version up at a local gathering a while ago, and many seemed to enjoy it. As for the difficulty ramp-up, there was a bug in that in the version shown in the video, so it didn't quite work as expected. The game gets progressively harder, the asteroids spawn more often and move faster and faster the further you make it. Thanks Kylearan for the offer - I'll let Mermaid speak about the tracker itself, but the replayer is really good, light on both CPU time and memory usage, excellent!
  13. A while ago I programmed a game for C64 called Spaceman Splorf, with graphics and music by Vanja Utne. Just for fun, we're now working on creating a version for the Atari 2600. we have tried to recreate gameplay and graphics experience as close to the original as you can come on the 2600. It's kind of a neat project, I guess this is what VCS coders way back had to deal with in many instances, trying to recreate something from a more advanced system within the constraints of the VCS/2600 hardware. Here's a preview video: https://www.youtube.com/watch?v=iCsrAk-R2LE You can read more on (and view videos) from the C64 original here: http://pondsoft.uk/splorf.html
  14. Thank you for your input guys! When it comes to PAL/NTSC, all my objects are using 16 bit coordinates, so I should be able to easily make the adjustments for 50/60Hz without going to PAL60. I will go with my 209 line display for now, perhaps try to track down someone with a NTSC console and TV to test it for me.
  15. I am working on a small game, with versions both for PAL and NTSC. Since I'm in PAL-land, that's what I use for real-HW testing. Only using the "official" 192 lines of graphics leaves quite a lot of unused screen real estate on PAL, so I am trying to find a happy medium that shows at least some more lines on NTSC, but without losing too much on a normal TV. Right now instead of the standard 3VSYNC+37+192+30 for NTSC I am now running 3VSYNC+33+209+17, which is showing OK in Stella. Can someone who has developed and ran stuff on real consoles on NTSC TVs give any hint on how many lines you can see on an "average" TV? Is 209 lines completely out of the question?
×
×
  • Create New...