Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by Cybearg

  1. Point. I wanted to avoid DPC+ because of the extra costs of a DPC+ board.
  2. Great to hear that it's possible! I just have no idea how the modifications you mentioned would be done, I'm afraid.
  3. Would it be possible to add functionality to the standard kernel that allows one to define a "texture" for playfield pixels for each playfield row? By "textured," I mostly mean instead of drawing a solid pfpixel, it would, say, skip drawing every other line (creating a sort of ladder look) or skip drawing every 4 pixels (creating kind of a brick look), or something along those lines? I've seen it done in games made with raw Assembly, but could this be a feature added to the standard kernel or is there simply not enough time during hblank to apply a texturing based on a table like so? pftexture: 0 ' 0 = solid pfpixel 0 0 8 ' 8 = ladder pfpixel 8 8 64 ' 64 = brick pfpixel 64 128 ' 128 = drawing every other pixel pfpixel 0 8 0 end
  4. See, I would have thought that it would just be a matter of wasting a few operations worth of time between the sprite drawings, causing them to be spread out more. I guess the problem is having enough cycles to check whether or not that time should be wasted, eh? It would need time to compare a value and make a jump so one branch would have the normal timing and the other branch would waste a few cycles between the first two numbers and the last four numbers.
  5. At present, the score is the 2 sprites alternating to be side-by-side. Would it be possible to modify the score so it displays the score in different pieces? For example, three digits on the left of the screen and three on the right? Or, in my case, two on the left and four on the right with a bit of a gap between,rather than all together in the center? Ideally, I'd like this to be set by a variable so I could show something like a counter and timer with the two-and-four split and then switch back to normal to display a six-figure score again. Also, on a somewhat unrelated note, I know that the score comes with sprites for values 0-9 normally, to display numbers, but does that leave an additional 6 possible values that could be set to display symbols instead (such as a symbol next to the number as a counter on the left and a little watch next to the timer on the right)? If so, how would you specify the BCD to display those A-F values?
  6. Alternately you could do a peek to see what tile the sub is touching when a collision is detected and adjust the y values of the peek to ignore the periscope.
  7. Ah, okay. So one must have individual screens for each, then switch which screen data is being read from. I guess it's about the same size-wise--it just requires more logic to tie it all together. Though why does the SCREEN statement allow offsets of 0-199 if it can only really bring in one screen (0 to 19) at a time? What's the use case for those larger indexes? EDIT: Got it, thanks tons, nano! It was indeed just a matter of moving some things around. 1. I moved GOSUB update_enemies to AFTER GOSUB scroll_screen. I don't think this necessarily did anything, but it didn't hurt anything. I can't remember why it wasn't there in the first place. :/ 2. I moved GOSUB set_enemies and GOSUB load_tiles to just after the WAIT, set to fire based on a flag bit toggled when offset_x = 7. Together, these fixed both the enemy weirdness AND tiles popping in with one fell swoop! scrolling_fixed.bin
  8. Thanks for the explanations, and I apologize if I was too bold on some of the questions. I didn't mean to make any implications about something being wrong--I was only curious.
  9. Thanks so much! Awesome! When using fixed numbers, do they need to be defined as #variable, since they're 16-bit values, or just as variable, since the examples in the manual seem to imply this is possible?
  10. I also have some more questions. 1. I've been adding some logic that checks to see what adjacent rooms are and block off/leave open walls depending on whether those rooms can be entered or not. I do this using plotchars like so: temp3 = screenindex - 4: temp3 = _Screen_Table[temp3]: temp4 = screenindex / 4 if temp4 = 0 || temp3 = 255 then plotchars 'fgfgfgfg' 1 48 0 However, the plotted tiles don't look quite like the others. While the already-set tiles have black backgrounds, the plotted tiles don't. Why is that? 2. I've gotten a bit used to IntyBasic, so I'm having to re-learn the simpler logic necessary for the batariBasic compiler. Why does the batariBasic compiler (and, by extension, 7800basic) seem "weaker" in the sense that it can't figure out any logic in if statements and allows only a few statements to follow an if, while in IntyBasic, I can write lines like this: IF CONT1.BUTTON AND pres_y = 0 AND pres_cool = 0 THEN #temp1 = ((Y1 + 1) /8) * 4: #temp1 = peek( $200 + #temp1 + (#temp1 * 4) + ((X1-9)/8)): IF (#temp1 AND 7) <> 3 AND (#temp1 AND 7) <> 2 THEN pres_x = x1: pres_y = y1: pres_col = (RAND AND 3): pres_state = (RAND AND 7): IF (flags AND 2) = 0 THEN flags = (flags XOR 2) or this: IF e_type(temp1) = 4 THEN e_x(temp1) = e_x(temp1) - 1: temp2 = e_y(temp1): IF temp2 < 0 OR temp2 > 96 THEN e_type(temp1) = 0 ELSE IF y1 < 48 THEN e_y(temp1) = temp2 - 1 ELSE e_y(temp1) = temp2 + 1 ... And it compiles just fine? 3. How many cycles does a plotchars routine take (or rather, how many times can they be called between drawscreens) and is there an efficient way to plot a column of tiles without requiring a new plotchar for each row? 4. Why are plotchars based on the on-screen pixel coordinates for x, but based on the tile's index for y? Why can't y also be per-pixel?
  11. Well, it will need to be restructured a bit as the else still assumes joy0down, so either I need to have another line redundantly checking for that, or I need to reverse the logic and add gotos so I can spread out the code in a way that will compile. EDIT: Got it working fine. Thanks. I've gotta say, I love the idea of the savescreen, restorescreen, and plotting. Adding pixels to a bitmap seems like it would allow one to do a lot of cool effects that may otherwise be difficult in purely tile-based systems. Is there a quick way to print characters to the screen that doesn't depend on specified alphadata? For instance, to create the effect of scrolling characters on-screen. Although maybe one could define the full phrase in alphadata, then keep shifting over one tile while writing the alpha data one character at a time?
  12. Warning: questions incoming! 1. How do I arrange data to be scrolled in for a very large playfield? I mean this both in the sense of how the data should be arranged (having more than 20 16-bit values in a "row" of screen data causes things to get all messed up) and how it should be scrolled in (since the SCREEN function apparently only works with offsets of 0-200, which means a playfield 10 screens long, which seems a bit short. Considering it takes about 45 seconds to scroll through a whole screen (at what I consider to be a pretty slow scroll speed), that would limit levels to being about 7 and a half minutes long. What if I wanted them to be longer, like 20 screens long? 2. How do I scroll in the cards smoothly and discreetly? At the moment, you can see the new card being written in on the far right. I'm probably just making a silly mistake, but here's the specific code for it: scroll_screen: PROCEDURE temp1 = (counter AND 15) IF temp1 = 0 THEN IF offset_x<=0 THEN offset_d=2:offset_x=7: GOSUB scroll_objects: GOSUB load_tiles ELSE offset_x=offset_x-1: GOSUB scroll_objects SCROLL offset_x,0,offset_d offset_d = 0 END ... load_tiles: PROCEDURE SCREEN screen0B, level_offset, 19, 1, 12 level_offset = level_offset + 1 END 3. I'm still having some odd sprite jittering issues at times. If you play the game (attached below), you may notice that enemies occasionally will jerk around, but I have no idea why. Any ideas? main.bas scrolling.bin
  13. Seems ironic to get a C&D for recreating a game that was essentially a questionably legal knock-off of Super Mario Bros.
  14. Ah, gotcha. So it's different with the 320 modes, then. I seem to have come across a... bug? I was trying to add the ability to move from one screen to another in the Adventurer demo, like so: temp1 = screenindex / 4 temp2 = screenindex & 3 if joy0down then if ypos < 172 then ypos=ypos+1:herodir=0:goto doneherowalk else if temp1 < 3 then screenindex = screenindex + 4: ypos = 8: gosub setlevel: goto doneherowalk if joy0up then if ypos > 8 then ypos=ypos-1:herodir=2:goto doneherowalk else if temp1 > 0 then screenindex = screenindex - 4: ypos = 172: gosub setlevel: goto doneherowalk if joy0left then if xpos > 8 then xpos=xpos-1:herodir=1:goto doneherowalk else if temp2 > 0 then screenindex = screenindex - 1: xpos = 152: gosub setlevel: goto doneherowalk if joy0right then if xpos < 152 then xpos=xpos+1:herodir=3:goto doneherowalk else if temp2 < 3 then screenindex = screenindex + 1: xpos = 8: gosub setlevel: goto doneherowalk The compiler handles the joy0down line just fine, but the other lines start to cause errors in the assembly, presumably because the compiler is creating duplicate label names: .L048 ; if joy0down then if ypos < 172 then ypos = ypos + 1 : herodir = 0 : goto doneherowalk else if temp1 < 3 then screenindex = screenindex + 4 : ypos = 8 : gosub setlevel : goto doneherowalk lda #$20 bit SWCHA BNE .skipL048 .condpart3 LDA ypos CMP #172 BCS .skip3then .condpart4 INC ypos LDA #0 STA herodir jmp .doneherowalk jmp .skipelse0 .skip3then .skipL048 LDA temp1 CMP #3 BCS .skipelse .condpart5 LDA screenindex CLC ADC #4 STA screenindex LDA #8 STA ypos jsr .setlevel jmp .doneherowalk .skipelse .skipelse0 .L049 ; if joy0up then if ypos > 8 then ypos = ypos - 1 : herodir = 2 : goto doneherowalk else if temp1 > 0 then screenindex = screenindex - 4 : ypos = 172 : gosub setlevel : goto doneherowalk lda #$10 bit SWCHA BNE .skipL049 .condpart6 LDA #8 CMP ypos BCS .skip6then .condpart7 DEC ypos LDA #2 STA herodir jmp .doneherowalk jmp .skipelse1 .skip6then .skipL049 LDA #0 CMP temp1 BCS .skipelse .condpart8 LDA screenindex SEC SBC #4 STA screenindex LDA #172 STA ypos jsr .setlevel jmp .doneherowalk .skipelse .skipelse1 . ; .L050 ; if joy0left then if xpos > 8 then xpos = xpos - 1 : herodir = 1 : goto doneherowalk else if temp2 > 0 then screenindex = screenindex - 1 : xpos = 152 : gosub setlevel : goto doneherowalk bit SWCHA BVS .skipL050 .condpart9 LDA #8 CMP xpos BCS .skip9then .condpart10 DEC xpos LDA #1 STA herodir jmp .doneherowalk jmp .skipelse2 .skip9then .skipL050 LDA #0 CMP temp2 BCS .skipelse .condpart11 DEC screenindex LDA #152 STA xpos jsr .setlevel jmp .doneherowalk .skipelse .skipelse2 .L051 ; if joy0right then if xpos < 152 then xpos = xpos + 1 : herodir = 3 : goto doneherowalk else if temp2 < 3 then screenindex = screenindex + 1 : xpos = 8 : gosub setlevel : goto doneherowalk bit SWCHA BMI .skipL051 .condpart12 LDA xpos CMP #152 BCS .skip12then .condpart13 INC xpos LDA #3 STA herodir jmp .doneherowalk jmp .skipelse3 .skip12then .skipL051 LDA temp2 CMP #3 BCS .skipelse .condpart14 INC screenindex LDA #8 STA xpos jsr .setlevel jmp .doneherowalk .skipelse .skipelse3 . ;
  15. That's exciting to hear! Glad it's so easy. In cases like Adventurer, why is the on-screen character "fat" compared to the raw .png that's plugged in? Is there any way to maintain the "proper" pixel ratios?
  16. Thanks for the info, RevEng. I guess it baffles me to imagine that it can handle 128-pixel wide sprites since I'm used to the 2600's unlimited height but limited width for sprites, unless you just mean extending the width by stretching the sprite (which doesn't seem to be the case with Adventurer, where the sprites are clearly 16 unique pixels wide, albeit stretched, 2x1 pixels). Too bad there doesn't seem to be a good way to keep pixels at their normal 1x1 size with 160A--the only way is apparently with one of the 320 screen modes, and those seem to come with a bunch of strange limitations in other areas. So if one wanted a 16-bit timer, for instance, you'd just have some branching logic that checks for carries and then increments the higher byte and the reverse for decrements? How would one then efficiently draw that 16-bit variable to the screen, particularly if one wanted to limit it to, say,10,000?
  17. Doesn't the 7800 use 16-bit memory architecture like how the Intellivision does? Maybe I'm totally mistaken, but I was under the impression that it did, in which case I'm surprised that 7800basic apparently doesn't support any kind of 16-bit variables. Also, if I understand things right, sprites in the 7800 are either 8x16 or 16x16, depending on the zone height, while background tiles and such are 8x16, 4x16, or 2x16, correct? Then how does the Adventurer example, using mode 160A, specify background tiles as 8x16 when the max should be 4x16?
  18. Alright, noted. I was just surprised that most 7800 games apparently go with only 160 pixels per screen rather than the more typical (for the time) 320. The NES does 320, doesn't it?
  19. Ah, of course. Thank you! I guess when I saw the stutter, I assumed it was that sort of weird effect I would get on the 2600 as well when you let something go too far to one side of the screen and it would freak out.
  20. Thanks! It's pretty bare-bones at the moment, but I have some ideas, and when those run dry, I'll be posting updates on the forums for feedback. It seems to have worked well for GOSUB. D'oh! This is exactly the problem! I was overflowing into memory of other arrays. Changing those 4s to 3s has fixed the problem. Thanks! I'm too used to C-syntax of for (i = 0; i < 4; i++) Is there any way to stop sprites from doing that funky stutter when they near x = 0 and instead just gracefully go off-screen?
  21. Are there any side-by-side comparisons of similar graphics in the different graphics modes? I'm not clear on what the color and pixel specifications of the chart actually mean in practical terms.
  22. I seem to be having some odd issues with memory getting written in unexpected ways (I presume). Or maybe I'm out of memory (doubt it)? I'm just starting to implement a modular system to allow multiple enemy types to dynamically share sprites 4-7. When the screen scrolls in, it checks the cards for being card 1-15 and, if it is, it replaced that card with a normal, blank card and spawns an enemy in that location (if an enemy slot is available). To accomplish these different enemies, I dimmed a fair chunk of memory: dim e_type(4) e_type(0) = 0 e_type(1) = 0 e_type(2) = 0 e_type(3) = 0 dim e_state(4) dim e_frame(4) dim e_mind( dim e_x(4) dim e_y(4) dim e_origin_y(4) The e_type is what kind of enemy it is, 0 for disabled. e_state handles the enemy's internal state (walking, attacking, waiting, etc.), e_frame handles which frame the enemy is on, e_mind gives two bytes per enemy that will be used as internal memory, like remembering a coordinate the enemy is aiming at or a location the enemy is walking to, e_x and e_y are obvious, and e_origin_y is the y-origin the enemy is based at, which will mostly be used with formula tables to create enemies that move in parabolic wave or swirling patterns. The enemies are then drawn on-screen like so: IF e_type(0) <> 0 THEN temp1 = e_frame(0): SPRITE 4, e_x(0) + $300, e_y(0) + $100, enemy_sprites(temp1) + enemy_colors(temp1) ELSE SPRITE 4, 0, 0, 0 The problem is, even though e_y is only set when the enemy is first initialized: set_enemies: PROCEDURE FOR temp1 = 19 TO 139 STEP 20 #temp1 = peek($200 + temp1) temp2 = (#temp1 AND $FF8) / 8 IF temp2 > 0 AND temp2 < 16 THEN poke $200 + temp1, 0: GOTO enemy_detected NEXT temp1 RETURN enemy_detected: FOR temp3 = 0 TO 4 IF e_type(temp3) = 0 THEN e_type(temp3) = temp2: e_y(temp3) = (temp1 / 20) * 8: e_origin_y(temp3) = temp1 * 8: e_x(temp3) = 152: e_state(temp3) = 0: e_mind(temp3 * 2) = 0: e_mind((temp3 * 2) + 1) = 0: RETURN NEXT temp3 END ... and e_x is only set during the normal updating procedure: update_enemies: PROCEDURE FOR temp1 = 0 TO 4 IF e_type(temp1) = 0 THEN GOTO enemy_set e_x(temp1) = e_x(temp1) - 1 IF e_x(temp1) <= 8 THEN e_type(temp1) = 0: GOTO enemy_set enemy_set: NEXT temp1 END ... For some reason, e_y is getting modified, resulting in the enemy flying upwards and switching to a 16-line sprite at times. Additionally, even if I modify the SPRITE declaration to draw the sprite at, say, 24 instead of the variable e_y, the sprite will move left (as it should) then vanish (it shouldn't), then it appears off the right edge of the screen, moving left until it meets the left edge of the screen before disappearing (as it should). I have no idea why it vanishes there, as if the x_value goes so low, it temporarily undoes the visibility bit or something. Here is the full source code and a compiled binary to show what I'm talking about: main.bas output.bin Any ideas what's going on here?
  23. Ah, I see. Well, the pokes still work with the wrong syntax, funny enough. How many cycles are used up by a poke compared to setting a normal value, like a = 5?
  • Create New...