Jump to content

skywaffle

Members
  • Content Count

    195
  • Joined

  • Last visited

Community Reputation

341 Excellent

2 Followers

About skywaffle

  • Rank
    Chopper Commander

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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
×
×
  • Create New...