LoginLogin

Gameboy Emulator

Root / Talk About Programs / [.]

SaladFingersCreated:
also let's say your programming level isnt good
Just because someone wrote bad code in the past doesn't mean they can' t improve, even if it is RGames. What makes you think you're so qualified to make these kinds of sweeping generalized judgements? Anyone with the willingness to work for a long time on something can make something decent. I doubt that this emulator is the most optimized it could possibly be, period, no questions asked. It might not run very close to real time, but with more optimizations, it can probably run quite a bit faster than it can currently.
but now the question becomes: is "a bit faster" worthy of wasting a long time?

also let's say your programming level isnt good
Just because someone wrote bad code in the past doesn't mean they can' t improve, even if it is RGames. What makes you think you're so qualified to make these kinds of sweeping generalized judgements? Anyone with the willingness to work for a long time on something can make something decent. I doubt that this emulator is the most optimized it could possibly be, period, no questions asked. It might not run very close to real time, but with more optimizations, it can probably run quite a bit faster than it can currently.
I agree, looking at myself. I went from making a horrible crappy hello neighbor clone into making a usable 3D engine over 2 years. That shows that putting time into learning and improving does help.

But still, I want to see if I can do anything to make it faster.
my ideasUsing BG tiles and Sprites, minimizing FOR Loops (if it uses a lot)
actual reasons why you might have trouble 0. Familiarization If you have not familiarized yourself with how the Game Boy works, I strongly recommend doing so if you're going to make any meaningful improvements. For your case specifically, you'll want to pay attention to which registers in memory correspond to drawing graphics. The PPU (pixel processing unit)'s I/O registers are hex $FF40 through $FF4B. There are a lot of resources that can help you find out what all of these registers do. I recommend the offical dev manual here: https://ia801906.us.archive.org/19/items/GameBoyProgManVer1.1/GameBoyProgManVer1.1.pdf 1. Sprite-Background Priority As far as I know, there is no way make anything (besides the console) display on top of the sprite layer in SmileBASIC. The sprites in the Game Boy can be draw behind parts of the background. How would you implement that without getting into computationally-expensive operations? 2. Sprite Limitations On the Game Boy, only 10 sprites can be drawn per line. The 11th will be cut off at that line. Not cut out entirely, just at the specific lines where there are 11 sprites in a row? How are you going to implement this sprite limit and have the sprites get cut off properly? 3. HDMA This is a big one. HDMA, among other things, allows for the background to be scrolled after every line it is drawn. This can be used to produce a wavy effect on the screen. SmileBASIC doesn't have anything that does this, so you would probably be stuck copying graphics a lot. And there's probably more than that.

There actually is a way to move sprites behind the BG. Both SPOFS and BGOFS have a z argument.

There actually is a way to move sprites behind the BG. Both SPOFS and BGOFS have a z argument.
Won't that move the entire background layer through? A specific pixel color need to be filtered and moved behind the others.

The largest problem for using built-in graphics is that the gameboy can change its graphics registers mid-frame, so the the frame can be partly drawn when data is changed

The largest problem for using built-in graphics is that the gameboy can change its graphics registers mid-frame, so the the frame can be partly drawn when data is changed
Yup. For example, a horizontal wavy effect in the background layer that I mentioned earlier can be achieved by changing the SCX register in a sinusoidal pattern on every line during H-Blank.

Probably X and Y, because those aren't on the original or GBC.

Just tried your emulator on SB4 with the Petit Converter tool, it works slightly faster than on the New 3DS, but not by much (around 5 seconds per frame). This says a lot about the possibility of emulation with SB4. We may not be able to get playable results.

Just tried your emulator on SB4 with the Petit Converter tool, it works slightly faster than on the New 3DS, but not by much (around 5 seconds per frame). This says a lot about the possibility of emulation with SB4. We may not be able to get playable results.
How long did I take you to get past the first screen of Tetris? (if you were trying that on sb4)

Just tried your emulator on SB4 with the Petit Converter tool, it works slightly faster than on the New 3DS, but not by much (around 5 seconds per frame). This says a lot about the possibility of emulation with SB4. We may not be able to get playable results.
What does it say?

Just tried your emulator on SB4 with the Petit Converter tool, it works slightly faster than on the New 3DS, but not by much (around 5 seconds per frame). This says a lot about the possibility of emulation with SB4. We may not be able to get playable results.
What does it say?
Hey! This was before you started announcing the progress of your emulator! Don't shame me! Really looking forward to your emulator!

Just tried your emulator on SB4 with the Petit Converter tool, it works slightly faster than on the New 3DS, but not by much (around 5 seconds per frame). This says a lot about the possibility of emulation with SB4. We may not be able to get playable results.
What does it say?
Hey! This was before you started announcing the progress of your emulator! Don't shame me! Really looking forward to your emulator!
Haha, sorry if that came of as rude. Been checking this thread for any potential updates. Had to react to your post. :)

Probably you can make a C# compiler,how did you make this? Just asking!