APPLE IIGS Super Mario GS v0.8b BROS GAME DEMO Lucas Scharenbroich Rob Hubbard's A Thing On A Spring

[@jonathanabela6098]

This music sounds GREAT with AirPods on

[@petsasjim1]

:) www.youtube.com/@petsasjim1/search?query=APPLE%20IIGS

[@GrayFromSprunkilol]

The music is so good

[@CatalinaMaxCisternasJofre]

This music sounds cool.

[@cristinamisaros8271]

Now this is what I call Mario.

[@petsasjim1]

:) www.youtube.com/@petsasjim1/search?query=SUPER%20MARIO

[@cristianmurgociu4569]

Heh. Found this game accidentally in the files of an Apple II emulator i installed. Pretty cool.

[@Highretrogamelord]

Neat music. Not as memorable as the SMB tune though. :D

[@petsasjim1]

Highretrogamelord YES,ITS A MOD.AND AS A MOD YOU CAN PUT ANY MOD OF MILLION MODS,IF PROGRAMMER WANTS.BUT IT IS VERY NICE TO SEE SUPER MARIO IN OTHER PLATFORMS.ADDITIONALLY,HE COULD DONE (HIS) AN ORIGINAL MOD.OR SIMPLY THIS FROM SUPER MARIOLAND : kzbin.info/www/bejne/in-klmRtn8aGoaM

[@arvizturotukorfurogep6235]

It's an arrangement of Rob Hubbard's A Thing On A Spring.

[@petsasjim1]

THANKS FOR THE INFORMATION :)

[@randygray3291]

RUN from the enemies, that is how to win. We all knew he was going to die first try, right? This is ALSO why we had Commodore machines.

[@CrazyDavePlants]

I agree

[@stuartfadeev4800]

HI I LIKE THIS VIDEO ,IT HAS NICE MUSIC ! GOOD PORT OF SMB1 FROM THE NES .

[@petsasjim1]

:)

[@benallen895]

IM ALSO USING CAPS FOR EVERYTHING

[@petsasjim1]

FINE

[@Rarestgameplayer]

Does it have no sound effects ??

[@petsasjim1]

UNFORTUNATELY , IT HAD NOT SOUND FX

[@asadava]

Is there a .2mg disk image of this?

[@petsasjim1]

HI bluetoons :) I FOUND IT HERE www.mediafire.com/file/nbf8b452m05yl6o/APPLE_IIGS_SUPER_MARIO_PLUS_HOMEBREW_GAME_DEMO_system.7z/file

[@petsasjim1]

APPLE IIGS SUPER MARIO BROS DEMO By Lucas Scharenbroich GAMES INSTRUCTIONS Super Mario GS v0.8b -------------------- Welcome, welcome, welcome! To those of you who have dowloaded a demo of SMB in the past, you will notice untold thousands of improvements this go around. If this is your first time, all the better! Now you will have the pleasurable experience of playing the classic Super Mario Bros. on your very own IIgs, be it emulated or otherwise. This is a an early version of the game. Even though I've been puttering with this project on and off again over the past 3 years, the game is not near it's final stages yet. Getting Started --------------- As with most downloaded software, just extract the contents of the .SHK into the directory of your choice. Since you're reading this document, you've obviously overcome this hurdle. Congratulations! You're now ready to run the program. Just double click on the executable as you would anything else. Note to shell users: The file must be launched with the current prefix set to its home directory. Ex. If lauching from a text shell, don't use :Hard1:Demo:SMB:SMB.Demo to launch it. Also, if you're using a shell, the program can take an optional level name that let's you begin at that level. Ex. SMB.Demo level13 When the game starts, a title screen will appear. Press '1' for a 1 player game, or '2' for 2 players. Pressing will exit the program. After a short delay, the current level will begin scrolling by, you can return to the main title screen at any time by pressing any key. Note for Emulator Users ----------------------- SMB IIgs has been tested with both Bernie II the Rescue and Kegs v0.53. It runs in both, but emulation accuracy and speed is superior in Bernie. I have not tried it in XGS, but I'm pretty sure it won't work due to the way that emulator handles ADB emulation. Keys ---- Use the numeric keypad for movement 8: Up (no effect) 4: Left 5: Crouch 6: Right Option: B button (turbo) Command: A button (jump) ESC: Ends the demo 'i': Interlaced mode. Draws half the scanlines for each frame. This boosts the frame rate, but can be visually aggrivating. Changes from v.(22/7) --------------------- 1) Little bug fixes 2) Put levels and music in their own data subdirectories 3) Added support for different music in each level 4) added a few more (incomplete) levels 5) Added animations after Bowser is killed 6) Spring blocks and vines are in 7) Most enemies are added Changes from v0.20a ------------------- 1) Fixes lots and lots of bugs 2) Optimized the rendering pipeline 3) New 'stretchy' transitions from small to big 4) More enemies added 5) Rewrote my tile compiler to perform optimizations. Reduced executable size by 10K. 6) Added an optimization to all sprites. Reduced executable size by 15K. 7) Executable is now about 220K down from 250K Changes from v0.12a ------------------- 1) added a FPS counter 2) changed renderer from PEI to PEA based. 3) eliminated need for a 27K buffer in Bank $00 4) new levels added 5) began work on platforms 6) general code clean-up Changes from v0.05a ------------------- 1) a 'real' title screen 2) game engine converted to scanline based system (faster) 3) most sprites done 4) all background tiles done (that I can think of) 5) support for swimming 6) fixed numerous little bugs 7) fixed a few large (Starship Trooper-sized) bugs. Disclaimer & Stuff ------------------ There is no guarantee that this program will work on any given system. I have a ROM 3, so if anyone with a ROM 01 has problems, let me know. Also, while the code is relatively stable (I haven't had a crash for a while) your milage may vary. Now that that's out of the way, here's what future versions will contain: High Priority: 1) Add in moving platforms and spring blocks (done) 2) Add vines (done) 3) Finish enemies (Lakitu, Red Koopa, Cheep-cheep, etc.) (done) Would like to have had done a week ago: 1) Support for water and swimming (done) 2) A Flagpole that works (done) 3) Let mario go on 'automatic' (done) 4) enemy-enemy collision detection (in progress) Off in the future: 1) Sound effects and music (music done) 2) Cool introduction (mostly done) 3) New Power Ups 4) New enemies 5) Faster, Faster, Faster (done) The game has _not_ been optimized for speed, size, or compatibility yet. If you have a problem that you can reproduce consistently, please let me know, but try to be nice about it. Enjoy! Lucas Scharenbroich [e-mail] *** SPECIAL THANKS *** * * * David Ong-Tat Wee * * Arekusu * * * * For their support * * and excellent * * suggestions * * * * These guys are * * _very_ clever! * * * ********************** _______________________________________________________________________________

[@petsasjim1]

Making New Levels This is the format for levels as they stand in the current version. I've included some sample assembly files in the archive that you can use as a basis for new levels. You'll also need to refer to the mario.h file for the correct numbers for tiles and enemies. Level format: notes - levels may be a max of 64K The first segment reference (SegOff1) will be where the player initially starts - there is a maximum of 255 local segments and 255 external references. This should be _way_ more than anybody will ever want to use Offset type Identifier Description ------------------------------------------------------------------------------- HEADER: String "SMBIIGS" Identifier string for a level file +6 CString[5] Level name i.e. " 1-1 ", "World" assumed +11 word Time Time limit in BCD format +13 byte NumSeg Number of segments +14 word SegOff1 Offset into file of first segment +16 word SegOff2 Offset to second segment . . . +XXX word SegOffN Offset to Nth segment +XXX+2 byte NumExtSeg Number of external segment references +XXX+3 CString ExtSeg1 filename of first external ref CString ExtSeg2 filename of second external ref . . . CString ExtSegN filename of Nth external ref SEGMENT: string "SMBSEG" Identifier string word Midpoint Midpoint of the level This is a bit field bit 15: 0 = normal 1 = water world bits 12-14: select song number bits 0-11: midpoint block number word SegWidth Width of segment in blocks word PlayerX Block where player begins word PlayerBase Baseblock where the player begins byte[32] Palette Palette to be used for this seg. word NumBaddies ;number of enemy charaters byte ID1 ;sprite ID word XPos1 ;Position 0-(SegWidth) byte YPos1 ;Position 0-12 byte ID2 . . . word NumRef Number of segment references word RefOff1 Blocknumber ofsegment ref word SegRef1 Segment to link to word DestHorz Destination Block in segment word DestVert Destination Vertical block Use -1 for DestHorz and DestVert to use the default values of PlayerX and PlayerBase word RefOff2 Blocknumber word SegRef2 Segment to link to word DestHorz2 word DestVert2 . . . word RefOffN Blocknumber word SegRefN segment to link to data LevelData 13*SegWidth bytes -------------------------------------------------------------------------------- NOTE: If a segment reference in a given segment is >0x00FF, then the low order byte should be ignored and the high order byte used as an index into the list of external references. The first entry in the external ref. list is assumed to be the name of the file to load after the current level is completed. ex. RefNum 0x0300 ExtRefList "World11" "World31" "Bonus" "World71" _______________________________________________________________________________ Technical Info: This is a place for me to tell about how the game animation works and what I have planned for the future. If anyone would like to try any of these ideas or would like code for what I have now, I will freely give it away. Currently, the graphics are drawn using a large PEA field. Data for the background is 'drawn' into the PEA instructions so it can be directly blitted to the screen. Also, a branch instruction at the end of the field creates a circular PEA field that allows for infinite horizontal scrolling using a PEA field 1 block wider than the visible screen. A difficulty with this is that when rendering to Bank 01, the PEA field has to be patched so it will exit at the correct spot. This is not too hard once one has figured out some things; like taking into consideration the fact that a PEA blit draws things in reverse. After a line is blitted to the Shadow SHR screen, whatever sprites are on that line are drawn. I've created a sprite format that breaks the sprites down into scanlines, so that they can be drawn one line at a time. An extra benefit of this is that sprites can be vertically flipped just by reversing the order that they are put into the drawing Queue. Vertical stretching is also easy. I've wrapped a version of Bresenhan's line algorithm aroung my sprite code, so I can stretch sprites as much as I want. It's a nice effect. I'm currently looking at ways to reduce the overhead of my blitter. Right now, my game has lots of small sprites, and the current method works OK, but a full background is blitted, and then the sprites are drawn on top of this. The result is some small flicker. Since large chunks of sprites are solid colored, I'm planning to extend my sprite format to include a 16-bit bitfield that maps out if a given word in the sprite is solid or not. This will allow me to blit 'around' sprites and reduce flicker for sure and possibly increase speed. There is a trade off, of course. There is more overhead involved with jumping in and out of the PEA field (instruction patching), so a threshold must be set. I roughly estimate that a consecutive run of 3 or more solid words are worth skipping. The 16-bit field will limit the horizontal size of the sprites to 64 pixels, but snce that's 1/5 the width of the whole screen I don't think it's a bad tradeoff. A nice feature of this method, is that it allows the engine to handle much larger sprites much better. The bigger the sprite the more area it covers, so the more area will be skipped during a background blit. There is the worst case of having a sprite that is a fence pattern, but then you're not any worse off than with what there is now. After that is implemented, I would like to work on adding a second scrolling background for parallax scrolling. By placing another background in Bank 0 and uing PEI instructions in the PEA field, 'transparent' words can be blitted from bank 0 to bank 1 and from there to bank e1. The big problem with this is that a given word can be only foreground or background, there's no easy way to handle single-pixel transparency. I plan to try this and see what the results look like. If the speed hit from the PEI's isn't too bad, this might be useful using bank 0 screen as the primary background and the PEA field background for special effect. Lots of thing to experiment with. As an aside, a fellow named Arekusu, from whom I've gotten most of these ideas, has been experimenting with variable length instruction fields. I've seen some of his work and it looks good, but I think it's a bit slower that what I've got right now. Well, that's it for now. Enjoy the code and email me for more info.

[@basicallysnake]

They really stole the tune from thing on a spring lol

[@tinaturner7007]

You used KEGS didn't you?

[@Rockanrolldelpais]

KEGS Emulator

[@canaconn2388]

Capslock much?

[@petsasjim1]

? ?