Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - CaptainMcClellan

Pages: [1]
1
Oh. You'd think that they would've had some sort of relay device that expedites the screen drawing considering the disparity there. I personally figured there was a draw buffer that was accessed by bankswitching then pushed to the screen. I'm not an engineer yet, so I don't even know if that'd be the most efficient. That's too bad though, I'd hoped the problem was software side. To me it seems odd to run a 16-bit device with an 8-bit processor though.

2
Hello everybody! I've been using this generator for quite a while now and I'm quite pleased with it. Despite this, there's all the issues. XD They're by no means "game-breaking" and many of them have already been addressed. Speaking as a total ignorant to how the TI-84 and co. work but having read the forums, my questions are as follows:

-Is the code available publicly for this? ( I seem to vaguely recall downloading the program from a Github, but maybe I imagined it? )
-Why can't the TI-84's regular clock-keeping be used for the RTC emulation? If it can, how long would that take to implement?
-( Vain pleas and hopes of GBC support through some miracle of programming.)
-Besides frameskip and scaling, there are no optimizations a user can do for speed?
-Is it stupid to ask for a battery bar that renders over the gamescreen? ( Of all the things I asked, this seems like the most dumb. )
-Why are the graphical drivers so sluggish for the colour screen as many have pointed out? Could they be replaced?
-I've read in the original project thread that calc-to-calc communication wasn't doable because of inconsistent timing. Is this still the case?
-The sound isn't supported, does that mean the app directly skips those byte-codes? If not, why not?

Beyond that, thank you all for your hard work and for the fruits thereof. I have enjoyed them ever since I acquired my CSE. :) I'd like to help, but realistically I don't think I can. At very least I'd like to snoop into the inner workings of this program. Also... there's some things that you should possibly look into with hardware modding a CSE. It is apparently possible to overclock them if you have divine skill. Would that be enough to bring about GBC support or is there more to it than mere processor power?

3
Ah.  Thanks calc84. As per the gamevar thing... What in particular would make that difficult to automate? (I'm guessing that each game stores variables differently and/or doesn't use the same coordinate system, requiring seperate coding for each game? ) As per Kirby appearing behind the water, I'll have to check the actual ROM in an emulator... in the future I'll do that for reporting purposes. It does seem a bit counterproductive for the player, so I'm unsure why Kirby team did so. I have a question, again about the sounds, why is it that you can currently only support two sound channels? Is it possible to map all four sound channels to a PCM channel instead? (I imagine that would probably slow the emulator and fatten it considerably, but is that even possible? )

4
@DJ_O: Thanks for your warm welcome!

Also, since I fear it was buried, I'll reask (or rather bring attention back to) the concept of bi-directional save conversions. My question was if he could add a seperate utility binary that can transfer the save files used by emulators or dumped from actual carts to the Appvars used by Ti-boy and vice versa. A simple yes or no will do, but if Ti-boy stores the save data based on how it's saved (I think I'm saying that right, basically since it emulates the gameboy my logic seems to think) couldn't there be a way to do so?

Besides that, I am still quite impressed by the functionality of this Emulator. And since it is Beta, I'd like to point out the few little graphical glitches. (Wish I had already made screen-shots to show what I mean.) There are two with Kirby on my actual calculator (Hence, no screenshots ) first, when Kirby goes into water (such as in Castle Lololo) he appears to be rendered *behind* the water. Well at least that's my guess as to why I cannot see most of his sprite most of the time while in water, while sprite tracking still works so it *is* still playable, this seems to be a particularly troublesome glitch. I'll try today to get Wabbit up and going on this comp so I can provide more helpful examples. Then the smaller thing is the roughness of the sprite tracking. Can you set it to only track the center of the sprite? I'm not sure if that would help.

5
Thanks. I figured it wasn't possible just as soon as I found that very topic on the original Ti-Boy thread. (Oops. ^^' ) Thanks though Ben_g. Now, I think I actually (possibly) thought of something useful *and* doable this time. A binary to convert Virtualboy (or general) *.sav files into the appvars for Ti-boy and vice versa. According to my checking of the Virtualboy the save types are: EEPROM SRAM and Flash (which presumably calc84 already knows). That way I can take my adventure on the go back to my computer and also I don't have to start from Dungeon 1 all over again when I had already made it to Dungeon 5. (I apologize again for being such a noob, I feel like I'm like annoying everyone with my constant posts because I barely have any idea of what I'm talking about at all and like know only 0.2% programming skills. )

6
Hi, me again. I just wanted to point out a small annoyance I have with the sprite tracking for Kirby. (You've probably heard it already) Whenever you set the Emulator to follow Kirby's sprite and then use the inhale attack the entire screen goes insane. (More accurately the camera jerks around in concentric circles trying to track Kirby's inhale as if the whole sprite were moving. ) It's nothing that renders the game unplayable or anything, but whenever you get a spare half-hour could you see what you might be able to fine-tune to stop this? (Or at least tell me why it's not possible, as you all so kindly did on the subject of removing sound opcodes.... Which I'm still trying to find a way to do. You were all right about it being a pain...) Also, I'm not sure if I've asked, but is there anyway to run a compressed ROM via the method in which this emulator works? (I'm thinking no based on scouring the forum thusfar, but hey, doesn't kill to ask.)

((PS. Link's Awakening YOU WILL FIT ON MY CALCULATOR! I DEMAND IT.))

7
Ok. Thanks all. (And yeah, I was thinking that it'd probably be very difficult, if possible at all.) Well, is there perhaps any sort of compression utility...? Probably not, it'd take up too much RAM required for the game to actually run. Still, if someone with a lot of time wants to find a way to compress it or somehow remove the sound data, I will greatly appreciate it! XD One last question: If I could open the ROM in a hex editor (or any other editor?), and painstakingly found the sound opcodes and removed them manually, would that render the game unplayable? (I knew that the ROM couldn't fit when I got it, so I guess that it's my fault for wasting time.) I'll report back with any results I find on my own, and keep up the good work friends!

8
Hopefully this isn't something that someone has posted before, I hate to be a forum spammer! Anyways, I was wondering if you could try to (for your next release) give the option to remove sound codes. (I think it's cool that tiboy is the only one that *does* support sound, but I have no use for the feature in the setting that I use the graphic calculators, ie school.) As per reasoning: I need the app filesizes to be smaller (I have no SE :( ) and I figure that, particularly for Link's Awakening, removing the sound and sound opcodes would cram the filesize to just small enough to fit on an 84+ without needing SE. Please respond soon about that. :3 Ciao!

Pages: [1]