Jump to content

Cybearg

Members
  • Posts

    951
  • Joined

  • Last visited

Everything posted by Cybearg

  1. So probably not good for much except a Yar's Revenge clone then, eh? Noted.
  2. Oh, woopsie! Thanks for pointing that out! On an unrelated note, what are the tiles from $D5 to $FF? Supposedly there are 256 GROM tiles, but it just looks like gibberish to me. Is it consistent, intentional jibberish that fits together somehow, or is it just RAM or code being read as card values? Any reason one would want to use it? Is there any way to reclaim those cards so they can be used?
  3. Maybe I'm missing something here, but shouldn't this: MODE 0, 0, 0, 0, 0 flags = 0; sprite_num = 0; FOR #i = 0 TO 480 PRINT COLOR 1, "\95" NEXT #i PRINT AT 0 COLOR 0, " " PRINT AT 20 COLOR 0, " " loop: IF CONT1.LEFT = 0 AND CONT1.RIGHT = 0 THEN flags = (flags AND $FE) IF CONT1.RIGHT AND (flags AND 1) = 0 THEN sprite_num = sprite_num + 1: flags = (flags XOR 1) IF CONT1.LEFT AND (flags AND 1) = 0 THEN sprite_num = sprite_num - 1: flags = (flags XOR 1) SPRITE 0, 8 + $700, 8 + $200, $7 + (sprite_num * WAIT GOTO loop ... Give me a screen of all blue except black in the upper-left, where sprites can be cycled? Instead, I get off-white in that area, as if the MODE 0 isn't giving me the color I asked for. What's up with that?
  4. I discovered an apparent bug in IntyBasic: the compiler seems to ignore everything after a poke() For instance, if I type: IF #temp3 > $8F THEN poke(#temp1 - 20, #temp3 - : GOTO post_delivered poke(#temp1 - 20, $80) poke(#temp1, (#temp2 XOR $8000)) ' Close off the chimney from more gifts post_delivered: Even if #temp3 is > $8F, it will still execute the following two pokes that it should be jumping over, because it ignores the GOTO. Similarly, with this (the same thing, logically): IF #temp3 > $8F THEN poke(#temp1 - 20, #temp3 - ELSE poke(#temp1 - 20, $80): poke(#temp1, (#temp2 XOR $8000)) ' Close off the chimney from more gifts The game never executes anything in the ELSE statement. However, if I do this: IF #temp3 > $8F THEN GOSUB decrement_chimney ELSE GOSUB close_chimney ... decrement_chimney: PROCEDURE poke(#temp1 - 20, #temp3 - END close_chimney: PROCEDURE poke(#temp1 - 20, $80) poke(#temp1, (#temp2 XOR $8000)) ' Close off the chimney from more gifts END Then the code executes as expected, with no problems. Incidentally, how many cycles do peek()s and poke()s take? Are they expensive, or pretty light?
  5. Now for a question that's more about basic game structure than anything specifically IntyBasic. In the game I'm working on, the basic goal is dropping gifts into house chimneys while avoiding enemies. While I could make levels of completely unique pieces, it seems to me like making a series of separate screens containing a building or two that scroll in and then switching between what data is being scrolled in would be the better option. The alternative would be a single huge table of level data that would be difficult to build, harder to test, and non-reusable. The trade-off, of course, is that, unless tile data was analyzed and modified after being read in, duplicate buildings would be obvious in their recurring colors and exactly identical shapes. For those of you out there with experience with this sort of thing, what is the wisest direction to pursue: one large, pre-designed level, or modular levels that can be rearranged to minimize ROM usage?
  6. Alright; I've carefully gone over it one iteration at a time and made a table of the best values. The winning formula seems to be: x_index = (sprite_x - 5 - offset_x)/8 Of course, that means that there will be occasions when the sprite misses when it's half-touching on the left and half-touching on the right, but - 5 - offset_x seemed the most reasonable "center" for that.
  7. And it's made even more complicated because the gift rotates, so it could be the width of a tile but offset up by 2 pixels, the height of a tile but offset right by 2 pixels, or rotated 45 degrees and fill the tile space more or less completely on each side. I tried pres_x - offset_x because I thought the same thing, but it seems to make it even more unreliable than it already is. There are just some occasions when you can hit the chimney dead-center, but the hit detection checks the tile next to it. Probably in the case where it just did a full tile shift, though I'm not sure.
  8. Yeah, if I was trying to get proper collision between sprites or sprites and backgrounds to prevent one from going through the other and it wasn't working out well, I'd probably do something akin to what you're suggesting there. The problem here is more that, between the sprite moving to keep up with the scrolling and the fact that it's likely not aligned with the 8-pixel grid, there are bad spots where the x-index of the tile will be off, so it will think that a present has missed the chimney because it's checking for the chimney on the tile beside the chimney, even though the gift is touching the chimney itself. I need an efficient, reliable way to compensate for the x offset of scrolling and the x offset of the gift sprite relative to the background tile that it collides with.
  9. I feel like an idiot for asking about this again, but I'm still having trouble zeroing in on what tile is beneath something, particularly when it varies by scrolling.. This code checks to see if a gift has fallen directly into a chimney (determined by seeing if the highest bit is set): IF (COL3 AND 256) = 0 THEN RETURN #temp1 = ((pres_y - 4) /8) * 4 temp1 = ((pres_x-8)/8) #temp1 = $200 + #temp1 + (#temp1 * 4) + temp1 #temp2 = peek(#temp1) IF (#temp2 AND $8000) <> 0 THEN GOSUB present_delivered: RETURN This is pretty much code given to me in an earlier question I asked. However, it doesn't always quite work. There are times, at certain points in scrolling, where the gift will fall off the edge of the chimney when it should be a hit or, worse, it will wildly miss even when it's dead-center. Here is a ROM with an additional sprite that blocks out where the sprite's hitbox actually is, to give a better view: gift_drop.bin What would be a better algorithm? I've fiddled with it for hours, adding and subtracting, trying to factor in offset_x, even checking across 2 or 3 tiles in line, but none of them have reliable, always-correct hit detection. Any suggestions for a better algorithm for calculating which tile a sprite is actually touching?
  10. Is there any way to break a long line of code into multiple lines in an editor with IntyBasic? In batariBasic, I believe you can do something like: IF (condition) THEN _ x = 1: y = 2 Where _ implies that the line breaks and continues on the next line, so x = 1 and y = 2 remain conditional.
  11. For whatever reason, I just can NOT wrap my head around this. I have four different subroutines that handle the stars in different ways, with varying levels of success. I'll give examples as I go. The main loop is like this: main_loop: GOSUB timer_tick IF (flags AND $10) <> 0 THEN GOSUB draw_stars GOSUB scroll_screen GOSUB update_states GOSUB set_player_states IF (flags AND 2) <> 0 THEN GOSUB crashing GOSUB set_sprites WAIT GOTO main_loop So keep in mind that that draw_stars is only executed if one of the flag bits are set. Here are the different star subroutines: clear_stars: PROCEDURE FOR temp1 = 0 TO 7 temp2 = star_locations(temp1) IF peek($200 + temp2) = $0933 THEN PRINT AT temp2 COLOR 0, " " IF peek($200 + temp2 + 1) = $093B THEN PRINT AT temp2 + 1 COLOR 0, " " NEXT temp1 flags = flags XOR $10 END draw_stars: PROCEDURE FOR temp1 = 0 TO 7 temp2 = star_locations(temp1) IF peek($200 + temp2) = 0 THEN PRINT AT temp2 COLOR 3, "\294" IF peek($200 + temp2 + 1) = 0 THEN PRINT AT temp2 + 1 COLOR 3, "\295" NEXT temp1 flags = flags AND $FFEF END clear_stars2: PROCEDURE FOR temp1 = 0 TO 7 temp2 = star_locations(temp1) IF peek($200 + temp2 - 1) = $0933 THEN PRINT AT temp2 - 1 COLOR 0, " " IF peek($200 + temp2) = $093B THEN PRINT AT temp2 COLOR 0, " " NEXT temp1 GOSUB draw_stars2 END draw_stars2: PROCEDURE FOR temp1 = 0 TO 7 temp2 = star_locations(temp1) IF peek($200 + temp2) = $0933 THEN PRINT AT temp2 COLOR 0, " " IF peek($200 + temp2 + 1) = $093B OR peek($200 + temp2 + 1) = 0 THEN PRINT AT temp2 + 1 COLOR 3, "\294" IF peek($200 + temp2 + 2) = 0 THEN PRINT AT temp2 + 2 COLOR 3, "\295" NEXT temp1 END And here are the tick and scroll_screen subroutines: timer_tick: PROCEDURE counter = counter + 1 END scroll_screen: PROCEDURE IF (counter AND 15) = 0 THEN IF offset_x<=0 THEN offset_d=2:offset_x=7: GOSUB update_back_cards ELSE offset_x=offset_x-1: GOSUB update_back_cards: pres_x = pres_x - 1 SCROLL offset_x,0,offset_d IF offset_d = 2 THEN GOSUB draw_stars2 offset_d = 0 END Now, whether that final GOSUB call is for clear_stars, draw_stars2, or clear_stars2 makes a huge difference in how the stars display: clear_stars: clear_stars.bin draw_stars2: draw_stars2.bin clear_stars2: clear_stars2.bin clear_stars2 comes the closest to being right, with the stars that are initially on-screen remaining solid regardless of scrolling, but new stars get the annoying flicker effect that the draw_stars2 stars do, and clear_stars just tries to hide the draw_stars flicker effect by making the stars disappear for a frame (a weak solution to the problem). What am I overlooking here, and how can I get the stars to remain in place like those top 3 clear_stars2 stars, but everywhere and regardless of what may scroll over the stars? As a final note, I call "flags = flags XOR $10" after the initial SCREEN statement to draw the stars to begin with.
  12. That's better than no dimensions at all. What are they?
  13. Got any dimensions for those various labels, such as the Mouse Trap one?
  14. Any info about the various label and manual dimensions? I don't have any actual carts or manuals to measure, myself.
  15. A few questions as I've made some more progress... 1. I'm still trying to pull off a stationary background tile while scrolling is enabled. Are there any examples in IntyBasic I could look at for this? I have the tiles themselves built and it works, until it gets to the point of the 8-pixel boundary where the tiles shift. Then I'm having a lot of difficulty with erasing the tile, waiting for the shift, then re-drawing the tile in the same place without any sudden flickering showing up on the screen. 2. Are there any examples of scrolling in a long series of tiles? There is a scrolling example, but it's just scrolling a single background. There's also a screen example, but it just re-draws parts of the screen at different points. I'm not sure how to combine screen and scroll in a way that smoothly scrolls in new tiles from a long data set that is, say, 200+ tiles wide. Any examples or tips for how to do this? 3. Are there any tools to aid in designing long tile sets? It would be awesome to design it using some visual editor that would spit out the data sets I need. Does it support the program Tiled per chance and, if so, how would that support be integrated (I've never used Tiled, I just know it's free and popular and 7800basic supports it). 4. Is there any good way to use the color stack while scrolling, or is that essentially impossible? I've experimented with arranging tiles in clever ways to pull off some nice effects thanks to the color stack, but those effects depend on a certain arrangement of tiles. Once some of those tiles scroll off-screen, the background colors get messed up as that careful stack arrangement is broken. Is this just an inevitability with color stack mode, or is there some trick for using color stack with scrolling?
  16. Would it be uncouth for homebrewers to create carts with front labels, like this:
  17. I'm pretty new to the Intellivision. I've looked at some pictures of cartridges and I'm a bit puzzled: do Intellivision carts typically have side labels (of the Atari 2600 variety), or do most only have end labels? What are the typical dimensions of the labels?
  18. Yeah, I don't know what they were thinking. Why split and reverse bits like that? Why would they design the architecture in that way?
  19. The manual doesn't state specifically, but it does link to the STIC documents that do. The information you're looking for is toward the bottom of that page, under "Background". The scrolling always affects either the top, left, or top and left of the screen, regardless of whether it's left or right, for instance. BORDER can be set to mask either the top, the left, or the top and the left, depending on your needs. Or you can just not use it.
  20. Oh, really? :/ I would have thought that bit shifting would only take a cycle or two a piece. Since there are only 32 16-bit variables available in IntyBasic, there still wouldn't be enough for 7 cards to exist in memory... Although I guess I could use 16 memory positions and handle the cards one at a time, but I can imagine that being very processor-intensive.
  21. Thanks for the explanation. As you point out, this is really only practical if I could load those cards from RAM. If that was the case, I could have 7 8-byte sections of RAM set aside, load the appropriate numbers into the last 6 8-byte blocks based on the score, then bit-shift the appropriate number of times until the score shows up correctly. This would be even more necessary if two numbers were on the same card. Am I understanding that right? It would be awesome if loading cards from RAM was supported. Also, since I'm sure I'm not alone in this kind of situation, a bit of built-in Assembly to streamline that shifting process would be nice, too. I really don't know Assembly well enough to be efficient with it, which is why I'm using IntyBasic. Could this maybe be put in the future feature list, nanochess? The complication with my game is that, with an action platformer, most of the game indicators can be implied on-screen with things like one's armor disappearing like in Ghosts and Goblins or the player getting bigger and smaller like in Super Mario. Scores can be implied with a number popping on-screen to show how many points the player is getting when finishing off enemies, like Princess Quest there does. The game I have could cut out displaying the score and how many lives the player has left could be displayed before the player begins, like how lives are displayed in Super Mario. However, there needs to be an ammo counter, and that's where it becomes more complicated. I could probably imply it by sacrificing an extra sprite, although that means 5 of the 8 sprites will be devoted to only displaying the player and implied HUD elements. Additionally, quite a few sprites use the two-sprite overlay trick to add additional detail and colors, meaning that many circumstances would come down to the player, a single enemy, and one projectile for each. Doable, but I would much prefer to be able to have two enemies on-screen at once, for additional gameplay possibilities. I could maybe free up a sprite or two by using the flicker effect, particularly for sprites that are using two sprites for extra detail, but I get the sense that's not as acceptable on the Intellivision as it is on the Atari 2600.
  22. But since a DEFINE statement can only load in one set of cards at a time and I wouldn't know which numbers were being used, I'd need the full 10-card set of all possible digits, 0-9, plus more for the bookends, otherwise the first digit and the last one would have stray pixels hanging off the ends. For zero, for instance, I have 8 frames for each number, so 0 is like this: ... But since all frames except index 0 have half the 0 going off the screen and half of a new 0 coming in, I'd need bookends on the left and right that finished this two-sided card without starting a new one, or else the score would always have trailing, empty pixels on its edges. Am I misunderstanding? What should the cards be like? Maybe not, although it's pretty weird to not have the score displayed in a side-scroller. There are other HUD elements I'd want to display, though, and while I COULD also display them in other ways (or rely on information given only in the pause screen or something), those alternatives are clumsy compared to a GUI and I think that they would detract from the ease of use of the final game.
  23. I reworked things a little bit and I think I may have the resources to pull off the effect of replacing GUI cards each frame of scrolling so the GUI appears still. The problem is that I'm having trouble wrapping my head around how it would actually work. I tried making versions of the cards that scrolled, but then I realized that's not sufficient, as you'd need 2 or 3 versions of every card to ensure that there was a starting card, a center card, and an ending card, but if one is replacing, say, the digits of the score, that means, at minimum 30 cards will be devoted just to holding GUI stuff and those 30 cards must be replaced each frame, which is impossible. How could such an effect be pulled off, then?
  24. Woo! Thanks, bogax! That's awesome! I presume that this effectively replaces the score (it seems to be just a jumble), but since one to set and replace those 6 sprite positions from more than the limited few available by replacing the score digits, this would be excellent for adding adventure or RPG elements into a game! Can one use both of your different minikernels, one for displaying dense text (like for character dialog), then switching back to the 6 individually-set symbols for inventory management?
×
×
  • Create New...