Cybergoth Posted April 7, 2008 Share Posted April 7, 2008 Hi there! I wonder for what kind of game such a display could possibly be good for? Greetings, Manuel hm.zip Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 7, 2008 Share Posted April 7, 2008 I wonder... Can you get a sprite on there also? Or more than one sprite? Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 7, 2008 Author Share Posted April 7, 2008 Adding the sprite is no problem at all. It'll most likely need a Sara chip for non-static display though. Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted April 7, 2008 Share Posted April 7, 2008 Hi there! I wonder for what kind of game such a display could possibly be good for? Greetings, Manuel Well, for starters, how about for posting screenshots? Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted April 7, 2008 Share Posted April 7, 2008 (edited) . Edited April 7, 2008 by Impaler_26 Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 7, 2008 Author Share Posted April 7, 2008 Well, for starters, how about for posting screenshots? Kinda ruins the gag then I was bored last night, so I wrote a tool that can read the level data from the C64 version. Even from the custom levels done with the built-in editor. Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted April 7, 2008 Share Posted April 7, 2008 Well, for starters, how about for posting screenshots? Kinda ruins the gag then OOPS! Sorry!! Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 7, 2008 Author Share Posted April 7, 2008 OOPS! Sorry!! Hey, bring it back, it's ok! Not that funny anyway Quote Link to comment Share on other sites More sharing options...
Impaler_26 Posted April 7, 2008 Share Posted April 7, 2008 OOPS! Sorry!! Hey, bring it back, it's ok! Not that funny anyway Ok! Would be nice if you make this game one day (maybe after jumpman?). Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 7, 2008 Author Share Posted April 7, 2008 Would be nice if you make this game one day (maybe after jumpman?). Well, I'm ready to go. Just bring on Sara replacement boards Quote Link to comment Share on other sites More sharing options...
Garak Posted April 7, 2008 Share Posted April 7, 2008 Kinda ruins the gag then Not for those of us who frequent a certain other forum. Garak Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted April 7, 2008 Share Posted April 7, 2008 Yeah, I have no idea what game that's supposed to look like. Quote Link to comment Share on other sites More sharing options...
+Nathan Strum Posted April 7, 2008 Share Posted April 7, 2008 I find myself in the most unfortunate position of actually having to agree with ZylonBane. Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 8, 2008 Author Share Posted April 8, 2008 Uihjah... It's the first level of Sokoban (aka Boxxle): http://www.mobygames.com/game/soko-ban/screenshots Brilliant puzzle game, you have to push the boxes to their target positions Quote Link to comment Share on other sites More sharing options...
ZylonBane Posted April 8, 2008 Share Posted April 8, 2008 Uihjah... Who? Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 8, 2008 Share Posted April 8, 2008 Adding the sprite is no problem at all. It'll most likely need a Sara chip for non-static display though. Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible. Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 8, 2008 Author Share Posted April 8, 2008 Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible. The screen layout is 19*16. Covering all 6 PF registers would require 6*16=96 bytes, maybe 80 if you combine the two PF0 columns. You'd require that RAM twice though, one set for each even and odd lines. And there's another problem: This technique will provide 4 tiles, but unfortunately the game normally requires 5: Void, Wall, Box, Target - AND - Box-on-Target Well, in theory you can replace Box-onTarget with just Box with some effort: If the Box gets moved away, instead of just leaving void, just restore the inital ROM state. There's still a problem remaining with ~ 5 out of the 50 levels that already start with a Box-on-Target, which is a bit harder to solve, since when in ROM I only know it's a Box, I actually don't know that if it gets moved away it must turn into Target then. Unless I keep extra tables and do some extra overhead for these exceptions. Quote Link to comment Share on other sites More sharing options...
uosipa llamxew Posted April 8, 2008 Share Posted April 8, 2008 (edited) Cool! Sokoban would be a great addition to the Atari game library. Didn't Andrew make a one level demo of Sokoban a while back? Personally, I'd like to see a version of Kwirk. It is similar to Sokoban in some ways, but has bigger blocks, turnstiles, and gaps where you have to push a block to make a bridge to reach your destination. Edited April 8, 2008 by mojofltr Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 8, 2008 Share Posted April 8, 2008 (edited) Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible. The screen layout is 19*16. Covering all 6 PF registers Of course! Well. Combine PF0 columns gives 10 bytes or RAM per row, so probably your maximum would be what you've got already, an 11-row board. Probably the best idea would be to narrow the board to 16 tiles wide so then you can get a 16x14 board. Or. :!: The green lines are static! So store them in ROM, store blue in RAM, and bingo, you can get a 19x16 board in 80 or 96 bytes of RAM. I missing something? EDIT: Just realized, that brings another box-on-target problem: the box-on-target looks like a wall. Of course, it solves your other problem of how to handle an initial box-on-target, and makes moving a box off target easy. You win some, you lose some. EDIT II: Maybe make box-on-targets blink slowly to distinguish them? Edited April 8, 2008 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 8, 2008 Author Share Posted April 8, 2008 I missing something? EDIT: Just realized, that brings another box-on-target problem: the box-on-target looks like a wall. Yes and yes EDIT II: Maybe make box-on-targets blink slowly to distinguish them? And the walls would blink in sync I thought I could possibly kill some RAM usage with lookup tables, since the actual data per line are only 20 bits. I'm thinking of something like (pseudo code): LDA PF1LeftPF1RightTable,X ; => 01011100 TAY LDA LookupPF1Left, Y ; => 00110011 STA PF1 ... LDA LookupPF1Right, Y ; => 11110000 STA PF1 So for 6 extra cycles I can get rid of one PF column, two for 12 cycles and maybe I can merge both PF0 also, unpack this live AND display the player AND get all the timings done, then it might be doable without a Sara board Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 8, 2008 Share Posted April 8, 2008 EDIT II: Maybe make box-on-targets blink slowly to distinguish them? And the walls would blink in sync No no no! Make just the lines in RAM, the blue lines (just the 'box') blink. So a box that is on target would blink, but the target would stay static. If I could make an animated GIF I'd illustrate but, well, I can't. But this is probably better, it's similar to how I stored the girder patterns in Squish 'Em: I thought I could possibly kill some RAM usage with lookup tables, since the actual data per line are only 20 bits. I'm thinking of something like (pseudo code): LDA PF1LeftPF1RightTable,X ; => 01011100 TAY LDA LookupPF1Left, Y ; => 00110011 STA PF1 ... LDA LookupPF1Right, Y ; => 11110000 STA PF1 So for 6 extra cycles I can get rid of one PF column, two for 12 cycles and maybe I can merge both PF0 also, unpack this live AND display the player AND get all the timings done, then it might be doable without a Sara board Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 8, 2008 Author Share Posted April 8, 2008 EDIT II: Maybe make box-on-targets blink slowly to distinguish them? And the walls would blink in sync No no no! Make just the lines in RAM, the blue lines (just the 'box') blink. So a box that is on target would blink, but the target would stay static. If I could make an animated GIF I'd illustrate but, well, I can't. Well yes, but the wall is on on both lines. Either that or it's looking the same as the target. I have 4 different tiles: 00, 11, 10 & 01 so no matter what I assign them, there's always two of them blinking. Or am I missing something now? Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted April 8, 2008 Share Posted April 8, 2008 (edited) Here's how I see it: Blank: 00 Box: 01 Target: 10 Wall: 11 Box-on-target: 11 for ten frames, 10 for ten frames, etc. So it would look like a wall half the time, but in theory the player could tell because it would be blinking. EDIT: Or hmmm. I think I'm misunderstanding your confusion. All blue lines are stored in RAM, all green lines are stored in ROM. Locations of boxes are stored separately from the array grid. (Is that not possible? What's the maximum # of boxes on a level?) So it would be no problem to remove boxes from the display RAM while still tracking them. Edited April 8, 2008 by vdub_bobby Quote Link to comment Share on other sites More sharing options...
Cybergoth Posted April 8, 2008 Author Share Posted April 8, 2008 Ok, I got you now. All the time I was assuming with "blinking" you were suggesting a color change for one of the lines Well, if it would switch even more rapdily between two tiles, with some luck one combination might possibly transmogrify into a really plausibly 5th tile EDIT: Or hmmm. I think I'm misunderstanding your confusion. All blue lines are stored in RAM, all green lines are stored in ROM. Locations of boxes are stored separately from the array grid. (Is that not possible? What's the maximum # of boxes on a level?) So it would be no problem to remove boxes from the display RAM while still tracking them. I didn't even get so far, with my confusion already kicking in before it. But yes, you'd need to store the boxes separately for this then. (I haven't checked yet what the maximum # of boxes is. Some 20-30 I'd assume) Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.