jrok

Thanks man. Yeah I am repurposing a lot of the Circus code, to see if it would fit in a more adventuring styled game. Do you mean how are they 16 bit wide? If so that's just flicker.

Thanks! I'm using the playfield to draw the lasers, which accounts for their fatness. I'll still working on the spaceship. I'm sure the color-blending for that and for other won't look as hot on real hardware, so right now I'll just try to optimize for emulation and alter the colors as necessary later on.

(Fixed a bit of bugginess) SciFiQuest1.bas.bin

Okay, horrible working title for a game, but that's all I got right now. As an experiment, I've taken a bunch of the work I've done with the engine for "Circus Galacticus" and have begun to port it over into more of a page-flip adventure model. I was always interested in trying something like Secret Quest and Adventure with a little more depth of gameplay and arcade action. The setting is an alien world on which the player has crash landed, in pursuit of a traitor on the run from the Galactic Empire. It would be a game of exploration and action, with multiple goals to accomplish in addition to finding the parts to repair your ship and leave the planet. NAVIGATION: I'd like to implement a fairly large and expansive world map, with some persistent elements and enemies. In addition to random encounters with weaker foes, I'd like to try to incorporate a few "roaming" bad guys like Adventure's dragons who are powerful enough that you'll want to avoid/evade them early in the game. Terrain will vary in shape, color, layout and effect, and certain special screens (like the screen containing your starship) will contain entrances into structures like bases and temples with their own submaps. ACTION: I'm using the shooting mechanic from Circus Galacticus, but I'd like to vary this up as well with some hand-to-hand combat. I've also ported over the quick-button-tap "dash" maneuver from CG, although now I've turned it into more of a Shatner-esque combat roll. I'm going to add to this over time, allowing player to shoot mid-roll so they can pull off flashy-looking kills. I've re-worked the AI for obstacle steering a bit, but I will also try to include some set piece challenges with more patterned attack movements. INVENTORY: The inventory will contain a picture of the item you are holding, controlled by the second joystick. I always liked the way Riddle of The Spinks was a little cryptic about how/where to use certain items, so I'm going to take a page out of that book, I think, and use manual-based hints for some items. SCORING: I'll be looking at Raiders of the Lost Ark as a frame of reference for the kind of scoring here. The game would be scored on goals completed, including various mini-quests like rescuing a hostage, killing a certain monster, blowing up the enemy base, finding an alien artifact, executing a traitor, etc. So scoring would be along the lines of "percentage complete" when you either die or escape from the planet. I'm a little curious if this is a game that people would be interested in playing. It would be much more complex to program then CG, but I feel like it would be a more interesting game in many ways. I've included a small demo (6x6 world,robot present in every room, no inventory).

It is an interesting prospect, but I'm not fully clear on the workflow here. What exactly is your involvement in this? Producer? When you say your games are Limited Edition and not for profit, what do you mean by that? Are you going to be selling these games?

Wow, it really does save a lot of ROM specifying "thisbank" (instead of a simple return). Why is that?

A few ideas: Use one hardware sprite for link, rather then two. Link was quite small in the original "Legend game", and it seems heavy-handed to use both hardware sprites to draw him. Use the resized ball for wielding the sword in four directions. Set CTRLPF to $31 and set the ballheight to "1" for when link is faced sideways to get a 8x2 sword, and set CTRLPF to $01 and ballheight to "7" for when he is faced vertically. No need to use a shield button, since the shield was automatic. Also, use a bitest to determine individual button presses. In other words, the sword shouldn't be in use constantly while the player holds the fire button, but rather appear for a second and then disappear until the player has released the fire button and pressed it again. If you're going with the standard kernal, employ 30hz flicker to get four free moving sprites onto the screen. If you're going to use the playfield to draw the walls/barriers of the areas, you might want to employ the Superchip, then store the shape data for one of the player sprites in RAM (whichever player sprite isn't used to draw link would be ideal, so you can maximize the number of enemy shapes.) You can also achieve higher resolution playfields this way. With the Superchip in use, you can add fixed point movement to both Link and his enemies with the zero page RAM without worry. This way, some monsters can travel slower/faster than others without extreme differences. For collisions, the native collision detection isn't so hot. Might want to consider tracking playfield position instead for smoother collision detection. Honestly though, wasn't "Secret Quest" supposed to be the Atari answer to Zelda? Creating an original adventure from scratch might be the way to go here. Attempting to sell something as iconic as Zelda could result in hordes of angry lawyers (the blue variant Lawyers, who I've heard are impervious to fire and the toughest to beat.)

You can also patternize the output automatically in SID2TIA to save ROM space by selecting the "Patternize" radio button. From what I can grasp this basically prevents the driver from writing redundant patterns into the code.

Thanks, Michael! This is exactly what I trying to figure out.

Well there was the Atari time machine prototype Nolan had invented. Sure it had bugs, but going forward in time a few years would have been no problem what-so-ever as long as a person were wearing their Mindlink. Read about it in my Nolan book!! Of course...how silly of me. I forgot that Mr. Bushnell invented the flux capacitor, "which is what makes time travel possible"! Actually, I've heard that he only saw a version of the time machine in Ted's garage. Baer then took out a patent on the time machine, but only Philips Magnavox would produce it. That's the reason CDs arrived before terrible music like ABBA became obsolete.

Was "Secret Quest" any good? Apparently it was supposed to be like "Legend of Zelda" for the Atari 2600. It's a decent game, but not incredibly special. It's really more of a technical achievement in terms of some of the elements "Nolan" was "designing", such as the passcode feature. But the gameplay wasn't really very varied or interesting and the graphics were merely okay. Rather than forcing a talented programmer to hammer out a poor man's Zelda, maybe Nolan should have "designed" something that played more to the Atari's strengths. And mapping scores of nearly identical rooms sounds more like work than fun to me.

Which was actually designed by Steve DeFrisco. Al's got the story covered pretty good on the page summary. By designing, Nolan meant "Steve, do a game like Zelda". "And Steve, while you're at it, throw a passcode save feature in there. I'm gonna go have a bubble bath."

All I want to know is if Nolan is "excited to again be designing games for the best selling system of all time."

Thanks Michael. Yes, this all makes much more sense than what I was (mis)remembering. One other question I had was, is there a way to go about defining a sprite shape in ROM and then accessing it in RAM. For example, suppose I wanted to draw some trees using the Superchip. I start with one tree: dim w_GRP0 = w016 dim r_GRP0 = r016 RAMterrain asm LDA #<r_GRP0 STA player0pointerlo LDA #>r_GRP0 STA player0pointerhi end w_GRP0[14] = %00000101 w_GRP0[13] = %00011010 w_GRP0[12] = %01001011 w_GRP0[11] = %01110111 w_GRP0[10] = %01011010 w_GRP0[9] = %00111111 w_GRP0[8] = %11011011 w_GRP0[7] = %11100111 w_GRP0[6] = %01011010 w_GRP0[5] = %11111101 w_GRP0[4] = %11011011 w_GRP0[3] = %00000001 w_GRP0[2] = %00000001 w_GRP0[1] = %00000001 w_GRP0[0] = %00000011 And then I add two more by reading the data written to the first tree, forming a vertical line of three trees: w_GRP0[15] = r_GRP0[0] w_GRP0[16] = r_GRP0[1] w_GRP0[17] = r_GRP0[2] w_GRP0[18] = r_GRP0[3] w_GRP0[19] = r_GRP0[4] w_GRP0[20] = r_GRP0[5] w_GRP0[21] = r_GRP0[6] w_GRP0[22] = r_GRP0[7] w_GRP0[23] = r_GRP0[8] w_GRP0[24] = r_GRP0[9] w_GRP0[25] = r_GRP0[10] w_GRP0[26] = r_GRP0[11] w_GRP0[27] = r_GRP0[12] w_GRP0[28] = r_GRP0[13] w_GRP0[29] = r_GRP0[14] w_GRP0[30] = r_GRP0[0] w_GRP0[31] = r_GRP0[1] w_GRP0[32] = r_GRP0[2] w_GRP0[33] = r_GRP0[3] w_GRP0[34] = r_GRP0[4] w_GRP0[35] = r_GRP0[5] w_GRP0[36] = r_GRP0[6] w_GRP0[37] = r_GRP0[7] w_GRP0[38] = r_GRP0[8] w_GRP0[39] = r_GRP0[9] w_GRP0[40] = r_GRP0[10] w_GRP0[41] = r_GRP0[11] w_GRP0[42] = r_GRP0[12] w_GRP0[43] = r_GRP0[13] w_GRP0[44] = r_GRP0[14] player0height = 44 Would there be a way to define the first tree shape in ROM, while writing its duplicates to RAM? Thanks again for all the kind help. Jarod. EDT: By "writing its duplicates to RAM," I guess what i really mean is targeting the individual lines of the sprite stored in ROM.

I'm working on a project right now that uses the Superchip to write the shape data for both player sprites. It's working fine, but I seem to recall a nifty sample which Michael (SeaGTGruff) wrote in which part of the data was stored in ROM and part in RAM. I have combed the forum until my eyes hurt, but I can't seem to find it. Michael if you read this, do you recall the sample program I am talking about? I couldn't find it by searching keywords nor by searching page by page. Thanks in advance, Jarod.

It would be great if there were a way to define the color rows for the P0 sprite (in exchange for M0) without doing so for P1 as well. Having a multicolor sprite take display priority without losing both missile objects would be helpful in certain types of games. Cheers, Jarod.

Er... You didn't attach the file to your posts in this thread as far as I can see. I SWEAR I attached the file? That does make a little more sense with the comments if thats the case, but you have to understand I did attach it? So Sorry to you if it isnt showing? And sorry for getting upset. Not what I want to see when I think im going to get helpful advice when I check my email. If you are having trouble attaching the BAS file for some reason, you could try copying and pasting the code into your post and enclosing it in code tags (or just highlight the pasted code and click on the code snippet button "< >" in the editing toolbar). Cheers, Jarod.

Actually, you can use on...gosub in the latest version on batari Basic.

The order of the labels in on-gosub are sequential... but so are your rooms! In other words, your grid isn't really a table with rows and columns, even though that's the way the player will percieve it. You have 25 rooms (a 5x5 grid), but they are just the values 1-25 (or, values 0-24, more usefully). How much you add or subtract to "screen" is what creates the illusion of columns and rows when the program is compiled. The on-gosub command isn't telling it to "go in order.. screen1, screen2, screen3." It's saying "jump to the label who's position is equal to the current value of the variable 'screen.'" You can sort of think of it as a bunch of "if...then gosub" statements compressed into a single command. For instance, suppose the following map layout is what I want to give the player the impression of, and that the bold number represents my current position on the map. 0 1 2 3 4 5 6 7 8 9 So I am on screen 3 (screen = 3). If I exit to the right (using the code snippet I wrote for you above.) The conditional statement would send me back to SetUpRoom with the new value of "screen", which would be "4." SetUpRoom on screen gosub screen0 screen1 screen2 screen3 screen4 screen5 screen6 screen7 screen8 screen9 The program would jump to the screen4 label, retrieve any playfield data, enemy info or anything else you want to jam in there, and then return to proceed with the game loop. So on the player end, they would now be on screen 4: 0 1 2 3 4 5 6 7 8 9 If I then exited down, the value of "screen" would be changed to "9" (4 + 5) before it sent you back up to SetUpRoom: SetUpRoom on screen gosub screen0 screen1 screen2 screen3 screen4 screen5 screen6 screen7 screen8 screen9 To the player, they would appear to have moved "down" one screen to screen 9: 0 1 2 3 4 5 6 7 8 9 Hope that makes sense. EDT: It's hard to illustrate the way I wanted to, due to the limitations of the site, but basically when you use "on...gosub" or "on...goto", the program will jump to whichever label corresponds to the current value of "screen."

Double post

I'm not sure why you say "it won't work." I'm doing something very similar to what I just described in a project I'm working on (12x12 grid), and it works just fine. The important thing is to think about what needs to happen at the screen edge in order to just do the minimum necessary to draw the screen. For instance the following things need to happen once when the player reaches the edge: 1) You need to wrap the player to the other side of the screen, at least one position before/after the opposite screen extent. Otherwise, you'd be trapped in an inifinite loop! if player0x = 16 then player0x = 143 if player0x = 144 then player0x = 17 2) When the screen limit is reached, you also want to either increment or decrement the value of screen, depending on whether you are moving across a row (+-1) or vertically along a column (+-5). if player0x = 16 then player0x = 143 : screen = screen - 1 if player0x = 144 then player0x = 17 : screen = screen + 1 if player0y = 20 then player0y = 71 : screen = screen - 5 if player0x = 72 then player0x = 21 : screen = screen + 5 3)Finally, you are going to want to send the program to a place where it can set up the next room. if player0x = 16 then player0x = 143 : screen = screen - 1 : goto SetUpRoom if player0x = 144 then player0x = 17 : screen = screen + 1 : goto SetUpRoom if player0y = 20 then player0y = 71 : screen = screen - 5 : goto SetUpRoom if player0x = 72 then player0x = 21 : screen = screen + 5 : goto SetUpRoom All of the above only happens once when the sprite position reads either 16, 144, 20, or 72, but won't loop over and over because you change the position before the next drawscreen. As for what happens at the "SetUpRoom" label, there are many, many ways you can go about that. The one I described would certainly work. For instance, consider the following example: dim screen = c player0: %111100 end SetUpRoom on screen gosub screen1 screen2 screen3 screen4 screen5 screen6 screen7 screen8 screen9 screen10 mainloop COLUP0 = $0E COLUPF = $44 if joy0left then player0x = player0x - 1 if joy0right then player0x = player0x + 1 if joy0up then player0y = player0y - 1 if joy0down then player0y = player0y + 1 if player0x = 16 then player0x = 143 : screen = screen - 1 : goto SetUpRoom if player0x = 144 then player0x = 17 : screen = screen + 1 : goto SetUpRoom if player0y = 20 then player0y = 71 : screen = screen - 5 : goto SetUpRoom if player0x = 72 then player0x = 21 : screen = screen + 5 : goto SetUpRoom drawscreen goto mainloop screen1 playfield: ................................ ................................ .....XXXX....................... ...XXXXXXXX..................... ..XXXXXXXXXX.................... ...XXXXXXXX..................... ....XXXXXX...................... XXXXXXXXXXXXXX.................. XX.XXXXXXXX.XX.................. XX...XXXX...XX.................. ................................ end return (rest of playfield rom defs) So, in the above, you are basically just sending the program to a label before the main loop. When it returns from the playfield definition, it will just move on to main game loop. Of course, you are going to want to do other things, like put limits on how many rooms left, right up and down you can move.

I think you sort of answered your own question: if screen = 136 then gosub screen136 Then make a label for screen136, define your playfield there (if that's what you were trying to do) and then put a return at the end. screen136 playfield: ................................ ................................ .....XXXX....................... ...XXXXXXXX..................... ..XXXXXXXXXX.................... ...XXXXXXXX..................... ....XXXXXX...................... XXXXXXXXXXXXXX.................. XX.XXXXXXXX.XX.................. XX...XXXX...XX.................. ................................ end return Although, if you are going to have a lot of different values for "screen," you might consider using an "on...gosub" command so you don't have to run so many conditional statements. on screen gosub screen1 screen2 screen3 screen 4 (etc...) Just make sure this doesn't go in your main program loop, since if playfield definition is what you are after, you don't necessarily want to define it every time you draw the screen. You could also replace the above with an "on...goto" command, then instead of return, just send the program back in to the main loop (i.e. "goto mainloop")

Thanks. I haven't abandoned it or anything. Still twisting the knobs and twiddling the dials. This is good to hear! I play the .bin file that you posted non-stop. Thanks. I've been distracted lately by a different game I've been writing on the side, which is more of an action-adventure game, similar to Raiders of the Lost Ark. I was actually aiming to get a demo of that up by the end of this week.

Thanks. I haven't abandoned it or anything. Still twisting the knobs and twiddling the dials.

I'm pretty sure that in the original Zelda, not pressing anything at all (joystick or buttons) was what activated the shield. I think you were vulnerable to missiles when you were moving or swinging your sword, but could block most of them as long as you were facing towards them and not pressing anything.