Cant wait for this to be published. (Take that, Gno Boy!)
Gameboy Emulator
Where is the release :D I been waiting. :D
Welcome Back, RaichuBender! 😄 It's been a while for this! 🌟hiIt’s a family reunion
owo gb emulator soon?Welcome Back, RaichuBender! 😄 It's been a while for this! 🌟hiIt’s a family reunion
He dies again...owo gb emulator soon?Welcome Back, RaichuBender! 😄 It's been a while for this! 🌟hiIt’s a family reunion
I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.
I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.You can’t do this because GB games are stored as execution data, not assembly (at least, I think). If this the case, it would be really hard to convert this to valid SmileBASIC code without creating a lot of random handlers, and the final file would end up taking up a lot of space. It would be easier to make an emulator than do this.
What is that supposed to mean? Could you please give me a compsrison?(I know what assembly is, just not what execution data is)Execution code (from the perspective of a Game Boy, although this applies to several other devices as well) is data that a device reads in order to execute something. This code was originally created from assembly (or another programming language that converted its code to assembly), and then was compiled into execution code. A good example of what execution code looks like is opening a .gb file (if you have one) in Notepad (on Windows). It’s a lot of unreadable gibberish. Imagine trying to make that into valid code. That’s where the problems come in. Did you think .gb files were assembly? If they were, it would be a lot easier to convert into native SB code.
I'd just like to interject for a moment. What you're referring to as boy, is in fact, Game/boy or as I've recently taken to calling it, Game plus boy. boy is not an operating system unto itself, but rather another free component of a fully functioning Game system made useful by the Game corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Many computer users run a modified version of the Game system every day, without realizing it. Through a peculiar turn of events, the version of Game which is widely used today is often called "boy", and many of its users are not aware that it is basically the Game system, developed by the Game Project.
There really is a boy, and these people are using it, but it is just a part of the system they use. boy is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Boy is normally used in combination with the Game operating system: the whole system is basically Game with boy added, or Game/boy. All the so-called "boy" distributions are really distributions of Game/boy.
A: also why not find the assembly code online if it's easier to use that? B:12Me12, I have no idea what you are saying, but it sounds smart so I'll agree.A: The point of an emulator is that it will be able to run any Game Boy game, not just assembly code. And still, assembly code would be hard to convert without adding handlers, as I said before. B: Even after researching it, don’t know what he said either, but his name is 12Me21 and you called him 12Me12 that’s offensive
no.I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.You can’t do this because GB games are stored as execution data
If this the case, it would be really hard to convert this to valid SmileBASIC code without creating a lot of random handlers, and the final file would end up taking up a lot of space.meaningless.
It would be easier to make an emulator than do this.≤.
hint.What is that supposed to mean? Could you please give me a compsrison?(I know what assembly is, just not what execution data is)This code was originally created from assembly
It’s a lot of unreadable gibberish. Imagine trying to make that into valid code.fallacy.
Did you think .gb files were assembly? If they were, it would be a lot easier to convert into native SB code.foolish.
=.A: also why not find the assembly code online if it's easier to use that? B:12Me8, I have no idea what you are saying, but it sounds smart so I'll agree.A: The point of an emulator is that it will be able to run any Game Boy game, not just assembly code. And still, assembly code would be hard to convert without adding handlers, as I said before.
B: Even after researching it, don’t know what they said either, but their name is 12Me8 and you called them 12Me8 that’s offensiveIt's the GNU/Linux copypasta and that you were unable to distinguish it from real information is disappointing (though I wish 12 wouldn't er... "help")
It isn’t stored as execution code? I thought it was. What is it stored as? Also the GNU/Linux thing makes sense now lmao Sorry for the massive misinformation, I guess. Guess I had some information mixed up or something.no.I have an idea for how you could "emulate" a gameboy on smilebasic. Instead of reading the ROM of a game and converting it in real time, you could create a script to convert the entire thing into smilebasic code and sprites/backgrounds(in smilebasic of course). You wouldn't be truly emulating a gameboy, but it would(in theory) truly emulate a gameboy game, and it would run very well. You could potentially totally so this for nes/SNES games, but I'm not the one making emulators here.You can’t do this because GB games are stored as execution dataIf this the case, it would be really hard to convert this to valid SmileBASIC code without creating a lot of random handlers, and the final file would end up taking up a lot of space.meaningless.It would be easier to make an emulator than do this.≤.hint.What is that supposed to mean? Could you please give me a compsrison?(I know what assembly is, just not what execution data is)This code was originally created from assemblyIt’s a lot of unreadable gibberish. Imagine trying to make that into valid code.fallacy.Did you think .gb files were assembly? If they were, it would be a lot easier to convert into native SB code.foolish.=.A: also why not find the assembly code online if it's easier to use that? B:12Me8, I have no idea what you are saying, but it sounds smart so I'll agree.A: The point of an emulator is that it will be able to run any Game Boy game, not just assembly code. And still, assembly code would be hard to convert without adding handlers, as I said before.B: Even after researching it, don’t know what they said either, but their name is 12Me8 and you called them 12Me8 that’s offensiveIt's the GNU/Linux copypasta and that you were unable to distinguish it from real information is disappointing (though I wish 12 wouldn't er... "help")