Jump to content

skywaffle

Members
  • Content Count

    195
  • Joined

  • Last visited

Everything posted by skywaffle

  1. I update the variables for any sprite positions and then redraw all sprites at that point. Is the jitter occurring each frame, or only on the frame the backtab is shifted?
  2. In my projects, my flow is something like below: START: Update the scroll offset variable. Check if the offset > 7 and if so, set a variable for screen shifting (IF OFFSET_X > 7 THEN OFFSET_X = OFFSET_X - 8: SCREEN_SHIFT = 1) SCROLL OFFSET_X, 0, SCREEN_SHIFT Update SPRITE positions WAIT Check sprite collisions IF SCREEN_SHIFT <> 0 THEN SCREEN_SHIFT = 0: SCREEN etc GOTO START
  3. I always update all sprites on screen after the SCROLL statement, and before the WAIT. Whenever you shift the backtab, you will also need to offset your people by 8 pixels.
  4. Off topic, but you can further simplify your code and avoid all the redundant conditional statements for drawing the screen for the various streets by using a table containing offsets for the starting point of each area. This can be very beneficial if your game grows larger. For example, if your all four street map data (screen_0, screen_1, screen_2, and screen_3) are made up of 40x12 tiles, you could have something like this: stage_offset: DATA 0 ' Street 0 DATA (40*12) ' Street 1 DATA (40*12) + (40*12) ' Street 2 DATA (40*12) + (40*12) + (40*12) ' Street 3 If the sizes are different, just make the changes accordingly, just keeping in mind to carry over the offset from the previous line. Instead of having all the conditional statements, have a single SCREEN command like this: SCREEN street_maps, stage_offset(street) + #muv+19, 19, 1, BACKGROUND_ROWS, #LANDSCAPE_WIDTH
  5. I don't know if you had resolved this yet, but typically when I am doing scrolling in games, I have my SCROLL command run, a WAIT statement after this (at some point in the loop), and then update the SCREEN. When you use SCROLL to shift the screen, the shift does not occur immediately, but will after the WAIT.
  6. You could possibly come up with a work around, such as displaying the stats if the screen is stationary for a length of time, and then blanking them out once the screen begins to scroll again. Maybe not though if there is a lot of continual scrolling.
  7. Unfortunately SCROLL ,,X shifts the entire screen. If you plan on pixel based scrolling instead of 8 pixel increments this would also offset your game stats as well.
  8. Does anyone know if having the extra GRAM would cause compatibility issues with prior games? This modification is simple enough to do, and the thought of having double the GRAMs available on stock hardware sounds like a lot of fun to play with.
  9. I just experienced a similar issue, but it was only on one of the games I tried. I used some plastx polish on a qtip and cleaned the tin contacts on the cartridge and it resolved it.
  10. One thing that helped me immensely was developing ways to compress levels down. For Super Mario Bros, fitting 32 stages and all the various secret areas was not going to happen without some kind of compression. The repeating backgrounds are drawn in 1x12 strips that are pulled from a table, and the level objects are drawn over the background as needed, but done with DATA PACKED tables that contain the following: Object type (single backtab tile, tile strip, enemy, warp, etc) Object attribute (tile strip size, warp reference point, etc) Screen X position Screen Y position Two 8 bit values in DATA PACKED are combined into a single 16 bit value. These are decoded back to two separate values by Value / 256 and Value % 256 respectively. I also pack all in game text the same way and try to avoid using PRINT statements all together using a subroutine like this: DISPLAY_TEXT: PROCEDURE FOR I = 0 TO TEXT_LENGTH #BACKTAB(TEXT_POSITION + I * 2) = (GAME_TEXT(I + #TEXT_OFFSET) / 256) * 8 + 7 + #LEVEL_BGCOLOR #BACKTAB(TEXT_POSITION + I * 2 + 1) = (GAME_TEXT(I + #TEXT_OFFSET) % 256) * 8 + 7 + #LEVEL_BGCOLOR NEXT END GAME_TEXT: DATA PACKED "GAME TEXT GOES HERE!" It's certainly not as convenient as using PRINT since you need to keep track of the offset of where to begin reading the text, but it has helped me reduce the footprint of all my game projects. Having a function at the beginning of the program as shown below also helps with more easily using the subroutine: DEF FN DISP_TEXT (A, B, C) = TEXT_POSITION = A: TEXT_LENGTH = B/2: #TEXT_OFFSET = C/2: GOSUB DISPLAY_TEXT
  11. I've had many issues in the past with having bulky code and needing to shrink the footprint some. consider replacing routines like: counter = counter + 1: if counter > 1 then counter = 0 with counter = 1 - counter or counter = counter + 1: if counter > 7 then counter = 0 with counter = (counter + 1) % 8 Those can free a small amount. Everything adds up if you have many routines like that though. Nanochess' example on using DATA routines for tables is incredibly useful. I use tables for just about everything, including movement patterns for enemies, jumping animation, enemy attributes, as well as stage configuration. If you using PRINT commands to place a few GRAMs or characters on screen, it can be leaner to use #BACKTAB instead. DO/LOOP tends to be more wasteful than having a label and a IF THEN GOTO statement. Having subroutines that check enemy backtab collision, updating enemy X or Y position, or changing enemy direction can be useful if you have many different enemy types. Each enemy can call on the same subroutines rather than duplicating the same type of code for each enemy type. I tend to use subroutines for lots of little things as well, like clearing sprites on screen, resetting enemy variables, or time delays (FOR I = 0 to DELAY_TIME: WAIT: NEXT).
  12. Here is a more complex example. Only 8 cards are used. Up and down animate the character. In other projects, I will have an offset table for stage bitmaps, so during level initialization, it can grab the appropriate bitmaps based on the stage's offset. pop_climb5.bas
  13. One solution to reduce some of the cards you are using, would be to use DEFINE VARPTR to update individual cards for character or enemy animation, as opposed to storing all of these at one time. Doing this not only frees up more grams for levels, but allows for much more complex animation. It's also nice to use DEFINE VARPTR for pulling in graphics for stage bitmaps as you need them. Attached is an example. definevarptr.bas
  14. Hello. Attached is an example. This one uses AND, however, changing to OR works if you are using background colors as the primary colors in the tile with black as a foreground color. Press up or down to fade in / out. tile_dissolve.bas
  15. This is a very interesting concept and neat to see in action. I'd love to see this used for higher color still pictures, as you can draw quite a bit and still maintain 60 frames per second. Out of curiosity, is there a way to to apply only the color information to portions of the screen without altering the GRAM card reference at a similar speed?
  16. I didn't realize that version 09 had broken two player support, so I have since removed it and replaced it with version 10. This version has some other minor bug fixes, and background music fades out and changes every few stages.
  17. Would there be any way to use poke to do sound that would allow for more easily switching channels? I ran into a similar issue when trying to read controller inputs for controller 1 or 2 using a variable without having to use separate cont1 and cont2 commands, but found that I could replicate those with peek.
  18. There was some sample code that showed writing two values to a specific memory address and reading them back to determine if the ECS was connected or not. I had not tried the ECS support on an emulator since I have yet to find the ROM for it, but own the hardware. With it running, the music stays clearer sounding since the effects are run on the ECS itself. Outside of the additional controller ports and sound, I didn't think ECS did much else. If I had more controllers, it'd be fun to do some kind of 4 player mode, or a different game all together.
  19. Attached to the first post is a new version. This one adds the following: Selectable Background droning sound off / on, or background music (default) ECS Support (Thank you GroovyBee for the simple detection logic). Double Jump animation bug fix causing broken animation Additional sound effects. Backtab collision bug fixes. New power up: One time fall protection New power up: Boots to increase speed (stacked for faster movement) New power up: Temporary invulnerability Other bug fixes with sound effect logic
  20. Hello, I was just wondering if anyone might have a solution to a problem that I am trying to figure out involving dynamic ECS compatibility. I wanted to have where if ECS was detected, full 3 channel music could play through ECS instead of the base PSG, leaving the remaining channels free for sound effects. Otherwise, the other method that came to mind would be to push sound effects to channels 5+? This sounded easy until I realized that variables can't be tied to the first argument in the sound statement. I was hoping for something cleaner than if/then statements that play separate sound commands for non-ECS or ECS. Thanks, Matthew
  21. I am guessing it doesn't like something about the ROM addressing. I am not sure what I am doing wrong though. This game uses $5000-$6000 and $C040-$FFFF currently.
  22. Maybe try using a BIN / CFG version? Here is a slightly newer build with some additions in that format. I noticed that I could not run the ROM file in Nostalgia, but the BIN / CFG works. jump08.bin jump08.cfg
  23. This game doesn't use any of exec functions. I have only played it on Jzintv for emulation, as it's what I use when doing quick tests. It doesn't need any particular flags to run. The title screen for the game is nothing more than a very primitive loop waiting for a side button to be pressed.
  24. A newer ROM has been uploaded This version adds the following: Stage 9 has a boss type battle (work in progress) Some enemy speeds are now based on level Rebalanced difficulty to allow longer play time, and slower difficulty ramp-up. Extra lives now every 1000 points Power ups added for faster shots, laser shot, and 1ups (currently randomly chosen and placed) New platform graphics are introduced every three levels. Pause bug in previous build would cause game to appear to freeze with two players playing and now fixed. Bug fix that would allow player to jump out of bottom of screen when no platform is there. Pause sound and extra life sounds added Auto fire and fixed / free shooting (moving or standing still while shooting) are now selectable before beginning game. Pong ball enemy now shows warning before spawning to prevent cheap deaths Medusa head enemies had a bug that would make them randomly stop moving or disappear which is now fixed. Saw blade enemies after level 5 will change direction 90 degrees when passing player. Pressing down + jump will allow the player to drop down to a lower platform All enemies now have different point values
×
×
  • Create New...