Kung Fu Pixel online
goerp
- posted on
- No Comment
The Forum64 and Protovision Game Compo (F64PGC) has ended and the jury reports are live:
https://www.forum64.de/index.php?thread/82809-f64pgc2017-sports-die-ergebnisse/
There are some ‘harsh but fair’ critcisms of my game Kung Fu Pixel. One of the common themes was: ‘the pixels are too big, I can’t see what’s happening here’.
Maybe if it is running in a browser, it is easier to see?
Running the game in a browser
The game has a specially made graphics and sound engine. That made me think it should be relatively simple to port this game to a browser while keeping the code in its binary form!
And it was (some caveats apply). I have a prototype online on https://sipke.gitlab.io/kung-fu-pixel/
The program is loaded in its binary form and then read into a 64K array, which acts as memory. This is ofcourse a simplified version of a C64, there are no ROMs.
C64 schematic (simplified)
This is a way to look at how a Commodore 64 works. The reality is of course far more complicated but for this instance it suffices.
The CPU reads from memory and updates it. The video chip (VIC) also reads from the same memory and exposes some of it’s state through memory. The synthesizer chip (SID) only reads from memory and the CIA chip is the go-between for memory and several peripherals.
For emulating the 6502 (6510) chip I used the CPU function from jsSID from hermit : http://hermit.uw.hu/software/jsSID-0.9.1-tech_comments.zip. I was planning to write it myself, but this looked so compact an nice I decided to use it.
Common code base
All game logic (code) data, graphics and music are layed out in memory. The idea is that you can reuse that without changing anything and emulate all the other parts (chips and interfaces). It would enable single source game development with deployment to different platforms.
I’m already at the stage that after each push to git, all changes are running online. So with one push of the button I have the game for the C64 and for a browser!
Setup:
In the original game everything is done on a sort of eachFrame() function (an interrupt on a specific point on the screen). Based on user input memory changes, game logic is applied, memory is updated and that memory is read by the graphics engine to draw a frame.
So it’s easy to decouple that. Every frame I start executing the code (calling CPU()) from the start of the interrupt routine by setting the program counter to that address. I keep on calling the CPU routine until the program counter has arrived at the end address of the interrupt routine (simple if statement). Thereby executing all code for one frame.
After that the javascript drawing routine can do its job by reading from the emulated memory. It’s drawing on a canvas. Very much what my custom C64 engine does, but with a different drawing technique. There are only 252 rects so that’s pretty easy for a browser.
The music is a different thing. I didn’t want to have to emulate the complete sound chip. So at the moment I check if the program counter in the CPU function is at the point where the music is changed and then I play an mp3 based on a certain memory location.
The option of sound effects in stead of music is therefore not working.
On of the things that is definitely needs more work is the joystick interface. The principle works; an interface writes values to a variable. The CPU reads that variable in stead of the memory location for the joystick.The interface now consists of some simple buttons that at the moment are pretty much useless. You can start a game and navigate the menu but that’s about it. In theory can attack but that’s not easy.
The game also runs on 60Hz in stead of the PAL 50Hz.
Conclusion
The reason I did is originally was to have the game run in a browser without complete emulation so it would run even on older hardware and on mobile devices.
But I also like the idea of a common code base that can be used in a Commodore 64 game and some other more modern platform. There are some game ideas, that I would like to develop on multiple platforms, so maybe I’ll work on it in 6502 assembly.
Next:
I will implement some better solution to control the game from the browser. It would be nice to have some simple Javascript synthesizer to attach to my setup, but I’m not sure that’s possible;
In my first prototype I had the game running from an existing javascript SID player, which also emulates a 6502 program, but because of buffering I couldn’t synchronize video with audio.
If I’m happy with my setup I will try to make something generic I can use in different projects. For game logic and data 6502 assembly works fine, but some games might not have all code run in an ‘eachFrame()’ setup, which may need very different solutions (code that is synchronised to each frame and code that is not).
It should be quite easy to have something that runs C64 character based basic programs without sound (especially PETSCII chars, user defined chars is a bit more work). I once did a port of a German tactical basic game to Excel. I could easily port it to the browser.
Something else
There’s also a review of all games of the F64PGC on this Russian blog:
You need to translate it of you can’t read russian (like me).
