load81 wrote:Have very many of you ported code from classic 8-bitters such as the C64, Apple 2e, BBC Micro etc. to FreeBASIC? I'm thinking about porting some C64 games that appeared in some type-in magazines I have floating around. I'm not as old as that makes me sound. Ha Ha.
Many of these programs had some parts written in BASIC, and others written in 6502 Assembly (or not even assembly... raw machine language, coded as a sequence of numbers). Unless you know wxactly what they are supposed to do, porting them is not easy
What's the best way to handle 8×8 bitmap tiles? Obviously, it's not going to be "overwrite the system font."
There are many examples, like this one: https://www.freebasic.net/forum/viewtopic.php?t=15902
Is there anything like sprite functionality in FreeBASIC? I'm just getting my head wrapped around the documentation.
The simplest way is to use the command PUT. It doesn't preserve the background, differently from a real sprite, but if you use a scrolling background you will have to redraw it at every frame anyway.
Otherwise, you can save and restore the background with GET and PUT:
Code: Select all
screenRes 800, 600, 32
' Draw a simple background.
for i as integer = 0 to 800 step 20
line (0,i) - (800, i)
line (i,0) - (i, 600)
' Set up an image and draw something in it.
dim img as any ptr = imageCreate (32, 32, rgba(255, 0, 255,0))
dim back as any ptr = imageCreate (32, 32, 32)
circle img, (16, 16), 15, rgb (255, 255, 0), , , 1, f
circle img, (10, 10), 3, rgb ( 0, 0, 0), , , 2, f
circle img, (23, 10), 3, rgb ( 0, 0, 0), , , 2, f
circle img, (16, 18), 10, rgb ( 0, 0, 0), 3.14, 6.28
dim as integer x, y, ox, oy
ox =- 100: oy =- 100
for x = 0 to 768
y = 300 + sin(x/57) * 200
' Restore the background.
put (ox, oy), back, pset
' Save the background that will be overwritten by the sprite.
get (x, y) – (x+32, y+32), back
ox = x: oy = y
' Draw the sprite.
put (x,y), img, alpha
' Wait for a keypress.
Other than needing to rewrite PEEKs and POKEs into platform agnostic functions what other issues am I likely to run into?
Different resolution, different controls, different management of the screen (on a Commodore 64 you could embed control character to clear the screen, change colors, and so on in a simple string, this doesn't exist in FreeBasic)
Oh, yeah. Timing. Lots of these games assume a ~1MHz clock in their control loops. What's the best way to keep code timing sane when porting to FreeBASIC?
Use the TIMER variable, or the command SLEEP, as other people have already told. Never assume that a FOR cycle will take a constant amount of time, not even on the same computer (execution speed might vary, in a multitasking environment, since processor could slow down a task to dedicate more time to another one)
I know I have to live without sound support for now. Bummer. But as near as I can tell from other threads here that problem is being worked.
Personally I developed an experimental library that should help you generate sounds in FreeBasic. You can find it here : https://sourceforge.net/projects/freebasic-sfx-library/files/
It can, among other things, be used to emulate the SID chip, and many others.