First post, pretty cool to see a community revolving around this. Brings back a lot of memories of learning programming on an Atari 800XL computer as the syntax is nearly the same. Anyways hopefully this guide will help some people, I may have missed some specific features to smile basic as I just downloaded and tossed this together over the past two days. It's under 100 lines of code and trys to cover most all the basics needed to make a simple game. It also shows both ways to start a game, and ways to improve it..
As I get time I'll edit this post to break it all down, show ways to improve performance, how parts of it work, how less code isn't always better, etc.
DISCLAIMER: Information in here might not be 100% accurate, or the best way to handle things.
=====================================
Tutorial Part One:
https://smilebasicsource.com/page?pid=269
Code: 5DW43NKE
What is Included:
-Program with emphasis on being under 100 lines of code
-Main program loop
-Sprite rendering/placement
-Simple graphical effects (Flickering)
-Sprite based collision detection
-Use of subroutines
-Enemy generation
Problems that need solved:
-No safeties for variable protection
-Variables written in confusing shorthand
-Checks for all subsections are written into the loop and not the subroutine
-No way to verify how well the program runs
=====================================
Tutorial Part Two:
http://smilebasicsource.com/page?pid=276
Code: 74H3LJ
What is Included:
-Manual declaration of variables (OPTION STRICT) this is something required by nearly any programming language, provides typo protection, and is a good habit.
-Subroutine checks are handled within subroutine, not the main loop
-Main loop design is much more modular showing how easy it is to add/remove new code
-Background star generation
-Variables are clearly labeled in a logical manner
-Method to measure performance of code
-Shows how more code can not only make a program easier to edit, but faster
Problems that need solved:
-General optimization (Benchmark mode gets 45FPS on O3DS. Granted this is also processing over 300 sprites at once, an impossible scenario but always room for improvement)
-Rendered objects clip over the scoreboard
-No user-interface (UI) to speak of
=====================================
ANALYZING OUR WORK
First we need a way to make sure what we are doing is having an impact, for that we need to add a benchmark tool which will run the game in a worse case scenario. For this mode we'll do the following based losely on a post by 12Me21 (Source: http://smilebasicsource.com/forum?ftid=310/):
-Add a timer
-Draw a many ships as possible (200 at once!)
-Leave collision detection on but disable the effects of it to prevent variation
-Disable VSYNC (Run as fast as possible)
New variables:
' Framerate Counter place this prior to any loop VAR G_PERFRUN%=1 ' Toggle that can track if we want to performance test VAR FPS_LOOP%=0 ' Used to track current frame at end of game loop VAR FPS_COUNT%=0 ' Tracks how many samples were obtained VAR FPS_SIZE%=300 ' Sample size to poll before reporting VAR FPS# ' Total frames minus the tracking frame VAR FPS_NOW# ' Calculated framerate ' Add this code to a subroutine or end of the main loop INC FPS_COUNT% ' INCREMENT CHECK COUNTER IF FPS_COUNT% >= FPS_SIZE% THEN ' CHECK IF SAMPLE TOTAL HAS BEEN REACHED FPS#=MAINCNT-FPS_LOOP% ' FRAMES TOTAL DURING BENCHMARK LOOP FPS_NOW#= (1/FPS#/FPS_SIZE%))*60 ' CALCULATE FRAMERATE CLS PRINT "FPS: "; FPS_NOW# ' PRINT FRAMERATE FPS_COUNT%=0 ' RESET THE COUNTER FPS_LOOP%=MAINCNT ' GET STARTING FRAME COUNT ENDIFWhile this isn't 100% perfect this code will provide an idea how well it's working. I took it a step further by forcing it to render an impossible number of ships (200) at once, and disabled explosions to prevent variation. Currently while rendering 200 moving ship sprites with collision, 100 moving star sprites, and some other items I'm getting 42.8FPS considering I can't get past level 18 I'll never see that number but I can use this to see if my changes are having an impact. (If I set it up for a realistic scenario of 20 ships I'm getting closer to 125FPS well over that magical 60 number) Next up... performance profiling PERFORMANCE BASICS: Simply put SmileBASIC will never be a speed demon, it has a lot of overhead against it and interpreted (non-compiled) languages are slow. That said, as a 2-D engine it is still very powerful, simple to use, and in many respects can put 16-bit era consoles to shame. Back on topic, the above program was written with the intent of staying under 100 lines of code. But adding code really improve performance, the idea seems backwards but it is true. Running this you also may be thinking "It's already running at 60FPS, why bother". Well as you add more and more logic, you begin to run the danger of slowing things up. The way the program is written, if we were to constantly miss V-SYNC this would result in choppiness, and possible screen tearing. Let's use the following block of code as a way to improve things: (Corrected: Thanks SquareFingers, and NeatNit)
@FLICKER IF L_T == 1 THEN BEEP 122 IF (L_T MOD 2) == 1 THEN SPCOLOR 0,RGB(0,0,0,0) IF (L_T MOD 2) == 0 THEN SPCOLOR 0,RGB(255,255,255,255) IF L_T >= 240 THEN L = 1 INC L_T ' INCREMENT THE TIMER RETURN ' RETURN TO THE MAIN LOOPCurrently we are doing the same math operation twice, it's unnecessary work and it's being done once per frame. This means that every second you are performing 60 unnecessary operations. Not only that but we are also doing an extra conditional check that isn't needed. So how can we fix this.
@FLICKER IF L_T == 1 THEN BEEP 122 IF (L_T MOD 2) == 1 THEN SPCOLOR 0,RGB(0,0,0,0) ELSE THEN SPCOLOR 0,RGB(255,255,255,255) ENDIF IF L_T >= 240 THEN L = 1 INC L_T RETURNWith three extra lines we made sure to only do that math operation once, and now we only have a single conditional check as this check is a true-false scenario. With that bit of change we just prevented 120 more complex operations from being performed per second. In the big scheme of things, that might not sound like much. But let's say we left something like that in @PROCROCK, and we have 10 ships on screen. Suddenly that 120 became 1200 wasted operations, and that is where we will look next...
