Jump to content

skywaffle

Members
  • Content Count

    188
  • Joined

  • Last visited

Community Reputation

341 Excellent

2 Followers

About skywaffle

Recent Profile Visitors

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

  1. 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.
  2. 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.
  3. 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
  4. 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).
  5. 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
  6. 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
  7. 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
  8. 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?
  9. 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.
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. 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.
×
×
  • Create New...