You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are in a prime time when developing for our favourite 8-bit handheld game console is easy. There are several solutions, you can pick from ASM, C, or graphics-based tools.
GameBuilder BASIC (GB BASIC) is a Fantasy Console that generates GameBoy compatible ROM. The upcoming full version would contain a BASIC dialect, a compiler, and a GUI-based development environment. GB BASIC is supposed to be an integrated environment, following the design philosophy of the Fantasy Console genre. The language is designed to be able to work as both DSL and generic programming language, in which a user can write code in a declarative way, also it preserves the ability to do fine operations. The compiler allocates variables automatically. Moreover, referencing to variables is handled by the compiler, other than by a programmer. You won't perceive the existence of ROM banks, since it's also handled automatically. Another major goal of the project is to shorten compile time as much as possible for quicker feedback and better prototyping/developing experience.
In the past few years, the community has been putting extraordinary efforts to make it possible for everyone who want to develop their own GameBoy programs. Without these work, I could not realize my dream - bringing BASIC to GameBoy homebrew developers and GameBoy gaming enthusiasts. The runtime is based on the GBVM project and compiled with the GBDK-2020 toolchain. The GBVM's convention, API, and features are fair complete and stable for some serious uses.
The compiler part is created from scratch (in C++) so that I can take fine control over the passes. Another benefit of inventing the wheel again is that a dedicated compiler could be precisely optimized. Compared to other architectures (i.e. generic frontend parser, plus customized backend generator), GB BASIC can finish the parsing, compiling, and emitting passes of a regular program in less than a second. It is an important feature that determines a Fantasy Console's overall responsiveness.
Personally I prefer to get gameplay done by code. The main reason of creating yet another development tool based on BASIC is that as a homebrew developer, I wish to use a tool with which I do not need to know much about the hardware, memory address, or pointer, and I should be able to use it even though I were not skilled in assembly or C; besides, I was grown up with BASIC, every 8-bit system should have a BASIC. Though this project is still in progress, I'll put continuous efforts into it, and I hope you could enjoy this new BASIC as I do.
As of the time of this writing, the project is yet a prototype. See the repository for a glance which contains an executable for Windows, several example programs, and other necessary assets.
There are not many options available for restricted system programming, for GameBoy in particular, you could choose either assembly or C. I regard BASIC as something between the low-level (assembly) and the high-level (C). GB BASIC reserved some flavours of the oldschool BASIC dialects: it accepts line number (optional), tokens are case-insensitive, implements a procedural programming paradigm, variables in it are global, has GOTO, etc. Compared to assembly and C, as a programmer, you do not need to know: bank, address, pointer, instruction conventions, code and constant space (ROM) allocation, variable space (RAM) allocation, asset referencing, etc. Regarding its objective project types and scale, I think such BASIC is at a subtle balance point of easy-to-use, expressive, speed, and productive.
To make user experience focused, it is designed that the all-in-one application will have all the asset pipelines built-in, as well as other integrated toolchains (for coding, asset editing, etc).
By introducing a VM layer other than compiling into machine code directly for the runtime, there would definitely be loss of speed. But it gets big gain in expressiveness. The API is designed to support both imperative and declarative paradigms. To make the declarative part more usable, the runtime has some advanced features, such as the thread feature which simplifies concurrent execution, and the Actor, Controller and Scene modules which could make the development work of specific genres of games easier.
As a developer from East Asia, I'm also very sensitive to Unicode support. GB BASIC can examine in-code UTF-8 strings, then generates their corresponding glyphs from a variable width font face (TTF).
This project has already implemented the following features:
A parser and a compiler that work in command line mode
A Graphics module
An Audio module for music and SFX
An Input module
A GUI module for Label with UTF-8, TTF support
An Actor module with metasprite, animation, motion, collision support, etc.
A Controller module
A Scene module
A Persistence module
A Serial module
...
All the example programs in the prototype version use temporary assets for test, due to lack of asset processing. In future versions, I will add some asset pipelines and more other features to push the application to a mature stage:
Implement asset pipelines to process real user made assets
Implement GUI-based editors to make assets
Implement a built-in emulator to test during developing
Add a reference manual
Add more examples
Improve the basic lib
Improve the Actor, Controller and Scene modules, etc.
Port the project to other operating systems
...
The following examples show a brief appearance of GB BASIC programs:
Hello World
Hello World
10print"Hello"20goto10
Maze
Maze
10print"%c", iif(rnd(99) <50, 47, 92);
20goto10
Thread
Thread
10let id = start lbl, 22, 720 update
30 join id
40print"!!!"50end5560 lbl:
70let a = arg
80let b = arg
90print"Args: %d, %d", a, b
100for i =0to4110print"i=%d", i
120call wait_frames 10130next140print"End"
sprite onoption sprite8x16_enabled, true
fill sprite(0, 8) ="Card"let a =new actor()
set actor property(a, position_prop) =79, 63
set actor property(a, frame_prop) =0, data16,8,0,0, 0,8,2,0, -128
set actor property(a, bounds_prop) =0, 15, 0, 15
set actor property(a, collision_group_prop) = 0x01
control actor a, topdown_player_behaviour
on actor(a) hits start hits_
gosub new_
let c =0print"Hit Callback Test"loop:
update
gotoloop
new_:
let b =new actor()
set actor property(b, position_prop) =rnd(0, 144), rnd(0, 128)
set actor property(b, frame_prop) =0, data16,8,4,0, 0,8,6,0, -128
set actor property(b, bounds_prop) =0, 15, 0, 15
set actor property(b, collision_group_prop) = 0x01
return
hits_:
let a1 = arg
let a2 = arg
soundonbeepwait30sound off
del actor(b)
c = c +1print c
gosub new_
end
[Home|All articles|Permalink]
We are in a prime time when developing for our favourite 8-bit handheld game console is easy. There are several solutions, you can pick from ASM, C, or graphics-based tools.
GameBuilder BASIC (GB BASIC) is a Fantasy Console that generates GameBoy compatible ROM. The upcoming full version would contain a BASIC dialect, a compiler, and a GUI-based development environment. GB BASIC is supposed to be an integrated environment, following the design philosophy of the Fantasy Console genre. The language is designed to be able to work as both DSL and generic programming language, in which a user can write code in a declarative way, also it preserves the ability to do fine operations. The compiler allocates variables automatically. Moreover, referencing to variables is handled by the compiler, other than by a programmer. You won't perceive the existence of ROM banks, since it's also handled automatically. Another major goal of the project is to shorten compile time as much as possible for quicker feedback and better prototyping/developing experience.
In the past few years, the community has been putting extraordinary efforts to make it possible for everyone who want to develop their own GameBoy programs. Without these work, I could not realize my dream - bringing BASIC to GameBoy homebrew developers and GameBoy gaming enthusiasts. The runtime is based on the GBVM project and compiled with the GBDK-2020 toolchain. The GBVM's convention, API, and features are fair complete and stable for some serious uses.
The compiler part is created from scratch (in C++) so that I can take fine control over the passes. Another benefit of inventing the wheel again is that a dedicated compiler could be precisely optimized. Compared to other architectures (i.e. generic frontend parser, plus customized backend generator), GB BASIC can finish the parsing, compiling, and emitting passes of a regular program in less than a second. It is an important feature that determines a Fantasy Console's overall responsiveness.
Personally I prefer to get gameplay done by code. The main reason of creating yet another development tool based on BASIC is that as a homebrew developer, I wish to use a tool with which I do not need to know much about the hardware, memory address, or pointer, and I should be able to use it even though I were not skilled in assembly or C; besides, I was grown up with BASIC, every 8-bit system should have a BASIC. Though this project is still in progress, I'll put continuous efforts into it, and I hope you could enjoy this new BASIC as I do.
As of the time of this writing, the project is yet a prototype. See the repository for a glance which contains an executable for Windows, several example programs, and other necessary assets.
There are not many options available for restricted system programming, for GameBoy in particular, you could choose either assembly or C. I regard BASIC as something between the low-level (assembly) and the high-level (C). GB BASIC reserved some flavours of the oldschool BASIC dialects: it accepts line number (optional), tokens are case-insensitive, implements a procedural programming paradigm, variables in it are global, has
GOTO, etc. Compared to assembly and C, as a programmer, you do not need to know: bank, address, pointer, instruction conventions, code and constant space (ROM) allocation, variable space (RAM) allocation, asset referencing, etc. Regarding its objective project types and scale, I think such BASIC is at a subtle balance point of easy-to-use, expressive, speed, and productive.To make user experience focused, it is designed that the all-in-one application will have all the asset pipelines built-in, as well as other integrated toolchains (for coding, asset editing, etc).
By introducing a VM layer other than compiling into machine code directly for the runtime, there would definitely be loss of speed. But it gets big gain in expressiveness. The API is designed to support both imperative and declarative paradigms. To make the declarative part more usable, the runtime has some advanced features, such as the
threadfeature which simplifies concurrent execution, and theActor,ControllerandScenemodules which could make the development work of specific genres of games easier.As a developer from East Asia, I'm also very sensitive to Unicode support. GB BASIC can examine in-code UTF-8 strings, then generates their corresponding glyphs from a variable width font face (TTF).
This project has already implemented the following features:
GraphicsmoduleAudiomodule for music and SFXInputmoduleGUImodule forLabelwith UTF-8, TTF supportActormodule with metasprite, animation, motion, collision support, etc.ControllermoduleScenemodulePersistencemoduleSerialmoduleAll the example programs in the prototype version use temporary assets for test, due to lack of asset processing. In future versions, I will add some asset pipelines and more other features to push the application to a mature stage:
Actor,ControllerandScenemodules, etc.The following examples show a brief appearance of GB BASIC programs:
Hello World
Maze
Thread
Graphics Primitives
Scene
GUI
Actor
Platformer Controller
Hit Callback
Colored
[Home|All articles|Permalink]
The text was updated successfully, but these errors were encountered: