Reserved
GameBoy emulator for SB4
Updates February 2020:
It might not look like much, but I was surprised at how fast it rendered the Nintendo-logo. It's still not lightning-fast, but that's just a matter of further optimizing.
I'll keep you guys up to date!
~Raichu
Updates April 2020:
Did a lot of optimizing this week. Check it out:
Super Mario Land 2
https://www.youtube.com/watch?v=9LapSf3XRrI
Pokemone Green
https://www.youtube.com/watch?v=jCwoNOc8kro
It's still not quite full speed and bug free, but it's getting there!
Spoiler
Hey y'all, It's been a while. I've mostly been busy with school and the likes. I have some good news, and perhaps some bad news. The good news is that I have been working on SmileBOY (my GameBoy emulator that I hyped up but never finished) and I'm already pretty far into developing it. The bad new is that I'm developing it for SmileBASIC 4 on Switch, which is Japan exclusive for now. Although I am thinking of porting it to the 3DS, since it's running at quite an acceptable speed, and I think with some frame skipping and speed hacks, it might run pretty decently on 3DS as well. I wasn't too happy with how I structured my code, so I restarted the project over and over again. That's why I was never really happy with it and I didn't want to show it off or share the source code. Not only that, but a traditional GameBoy emulator just doesn't run very well in the slow (but awesome!) interpreted language that is SmileBASIC. I have found solutions for this by analyzing the source code of programs by clever Japanese developers. (In fact, I'm using the PC88 emulator's Z80 CPU code as a base for the GameBoy's CPU in SmileBOY, heavilly modified of course.) To achieve better speed, I'm using lookup tables for simple math operations that would normally cause a lot of overhead. It's the reason why SmileBOY has been unbearably slow up until recently. Simple things like adding two numbers together doesn't sound like it'd slow down the emulator. But if you do this a few thousand times every frame, it adds up quickly. By using a lookup table, the emulator can run significantly faster. So instead of doing something like:'simple add instruction using DEF-block RESULT = ADD(&H7F, &H4C) DEF ADD(in0, in1) RETURN (in0 + in1)AND 255 ENDI take the value from a two-dimentional array with the values pre-calculated:
'simple add instruction using lookup table
RESULT = ADD[&H7F, &H4C]
@init_ADD
VAR in0,in1
DIM ADD[256,256]
FOR in0 = 0 TO 255
FOR in1 = 0 TO 255
ADD[in0,in1] = (in0 + in1)AND 255
NEXT in1
NEXT in0
(these examples are over-simplified, but with other things like flags to worry about, lookup tables are very convenient and fast)
I think with a lot of clever tricks like this, I can achieve full speed on Switch and acceptable speed on 3DS.
Here is a picture of the GameBoy's boot screen, rendered as a tileset:
It might not look like much, but I was surprised at how fast it rendered the Nintendo-logo. It's still not lightning-fast, but that's just a matter of further optimizing.
I'll keep you guys up to date!
~Raichu
Spoiler
UPDATE: Ok, So I got the Tetris working (for the most part). I made a lot of progress the past few days. I feel like I participated in one of those hackathon/game jam thingies... Anyway, I implemented BG graphics, VBLANK interrupts and joypad input. The framerate swings between 12 and 30 fps. I still have a ways to go before I get to 60, but I think it's possible, even with sprites to implement. Video: ;) https://youtu.be/Zxvcwx4PNVA What you see are the BG and WINDOW-maps rendered as SB's BG tiles. There are no sprites yet, so this is basically unplayable. The BG maps get updated every time a value is written to the appropriate area in memory. This is pretty slow, so I already know where to optimize. Obviously, this is not how the GameBoy actually renders it's screen, but it is a nice speed hack, and I might make it an option allongside regular scanline rendering.Spoiler
Sorry that I'm not as active on here as I used to. Busy life and stuff... I post videos on Twitter every now and then to show progress I've made for my emulator. Here is one such video: https://youtu.be/kklcpBDwCac This is already a lot faster than 4 seconds per frame! I got Tetris running at full speed once, but after adding the timer register and it's features, as well as more graphical and sound related stuff, it no longer wants to go above 40 fps. But I think that's just a matter of further optimizing. I'm very optimistic that I can make this run very smoothly.
I never thought that lookup tables would improve basic operations so much, and now I feel foolish for never even considering that being a possible speed boost lol. Good luck getting this playable!
he protecc he attacc but most important he baccHe bacc indeed
I never thought that lookup tables would improve basic operations so much, and now I feel foolish for never even considering that being a possible speed boost lol. Good luck getting this playable!Heya, how's it going It's not ideal in every situation, but setting the flags-register correctly after an arithmetic operation is normally a pain. There is no real way to do it in a convenient or fast manner, since I can't use structs. In those cases, pre-calculating it and getting it from an array is a lot faster (and the code looks a lot less messy). Currently experimenting doing something similar with lookup tables for tile rendering. Right now I have to check the palettes, get color data from the values in memory and put them in an array or BG/T map. If I can speed the former routines up by using a massive lookup table instead of calculating it every time before I put it in the frame buffer, I think that'll speed things up even more. I already achieved 60+fps in Tetris today, so it is much faster already. Here's hoping SB3 will have enough memory to hold the lookup tables, as well as a frame buffer. I already struggled to load larger ROMs. Pokemon Gold and Silver are a big no-no if you want to load them in one go.
Sorry that I'm not as active on here as I used to. Busy life and stuff...
I post videos on Twitter every now and then to show progress I've made for my emulator.
Here is one such video:
https://youtu.be/kklcpBDwCac
This is already a lot faster than 4 seconds per frame!
I got Tetris running at full speed once, but after adding the timer register and it's features, as well as more graphical and sound related stuff, it no longer wants to go above 40 fps.
But I think that's just a matter of further optimizing. I'm very optimistic that I can make this run very smoothly.
[poll=p719][/poll]
I really want to deliver quality, and a great user experience. As such, I'm hesitant whether I want to release my emulator at the current state.
All a have now, besides the emulator itself of course, is a simple ROM-loading menu and two buttons mapped to saving and loading states.
There is no documentation or guide on how to use it yet, and the code is all over the place, with commented-out code blocks everywhere.
Battery saves don't work yet and most of the games I've tested don't work yet, because I have to debug the emulator some more.
That said, with SB4 releasing in the west later this month, I'd love to show off the "power and potential" of SB4.
But then again, I think it's still better to release it when I'm happy with it, because I know I can do better.
Wow, this is looking fantastic! I never really thought this would actually be possible.Thanks! :D People underestimate the power of SmileBasic sometimes I feel. With the proper optimization, minimizing things like drawing on the G-canvas to only when necessary and looking for faster alternatives for slower operations, programs will run a lot smoother.
Oh my gosh, this is incredible. I never thought I'd ever see something like this happen. HUGE kudos to you!! 👏👏👏
Oh my gosh, this is incredible. I never thought I'd ever see something like this happen. HUGE kudos to you!! 👏👏👏Thanks! Having a lot of fun optimizing. Comparing this with what I had around a year ago brings a smile to my face.