but now the question becomes: is "a bit faster" worthy of wasting a long time?also let's say your programming level isnt goodJust 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.
Gameboy Emulator
Root / Talk About Programs / [.]
SaladFingersCreated:
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.also let's say your programming level isnt goodJust 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 still, I want to see if I can do anything to make it faster.my ideas
Using 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.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 changedYup. 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.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?
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?
Haha, sorry if that came of as rude. Been checking this thread for any potential updates. Had to react to your post. :)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?
Probably you can make a C# compiler,how did you make this? Just asking!