Recent Posts

Pages: 1 [2] 3 4 ... 10
11
ASM and machine code are basically the same thing. :P :P :P
12
Computers & Programming General / Re: A Game Boy game that emulates a more advanced CPU
« Last post by Hooman on February 10, 2019, 09:19:06 AM »
Hmm, interesting site.

And that's not so much ASM as it is machine code. Way more cool when you can program with machine code.  8)
13
OutpostHD / OutpostHD v0.7.11 Preview #2
« Last post by leeor_net on February 09, 2019, 11:28:50 PM »
So I got a lot more done than I expected. As per the Roadmap on GitHub, v0.7.11 is almost ready for release, there's a few things I want to test and consider building a few extra features before I push it.

https://github.com/ldicker83/OPHD/milestone/10

So, on to the preview screenshots:


These screenshots show taking advantage of the cross-platform message box's that I added to the code -- sure, it's not as 'nice' as having a skinned in-game Window but it's a hell of a lot easier and takes advantage of the host OS's ability to stop execution while waiting for user input (modal dialog's). So far on Windows I have this done using Win32 API calls. It's done through SDL2 on all other platforms. In the future I'd like to have these functions use the host OS's code to pull up these message box's but eh, long term goal.

Moving along, I've pulled the AiVoiceNotifier from the code -- I liked the idea of having an AI that would yell at you if you're making a mistake but ultimately it requires resources and assets that I just don't have the ability to deal with. Plus, the ones I used were very vague and not terribly informative so that's where the message boxes come in.


I want to add in a resource panel and update the StructureInspector to include details about why a Structure is disabled or idle (it currently does some basic stuff with reasons for it to be disabled but may not be specific enough (e.g., insufficient population is accurate but doesn't tell you exactly what kind of population is lacking and how much you need).

Lastly, looking at the structure icons at the bottom of the screenshots you can see the new icons that White Claw has been working on are finally in the UI now. I finally stopped being lazy about it and made it a thing. Woot!


So yeah, much progress made on this version, looking forward to getting it out the door soon. :D
14
OutpostHD / Re: OutpostHD v0.7.11 Preview #1
« Last post by White Claw on February 08, 2019, 07:50:01 PM »
Hope you feel better soon, Leeor. :)
15
OutpostHD / OutpostHD v0.7.11 Preview #1
« Last post by leeor_net on February 08, 2019, 07:17:40 PM »
Hey all!

Been a couple of weeks since the release of 0.7.9 and a couple of new users have been very helpful in providing feedback on how to make the game more enjoyable.

I released 0.7.10 as an interim patch to fix some really glaring bugs that I managed to overlook (yay me for not testing properly), discovered that I've been dealing with diabetic ketoacidosis which had absolutely killed my productivity for the last couple of months (it's being treated now and I'm coming back to life), etc.

Anyway, 0.7.11 is going to address some basic usability issues. The biggest change is going to be taking advantage of the new cross-platform message box code I put into 0.7.9. The AI Voice is going to be taken out of this release (should reduce the download size) in favor of much more descriptive messages.

Other changes will include just some basic information that's not being provided to users (like structure build time, mine extension remaining time, etc.) and other minor changes that should make the game easier to pick up.

I wanted to have it done for this weekend but having to take off work to get treated means I'm working this weekend... so eh, but maybe next week I'll have a new update out the door! :D
16
Computers & Programming General / Re: A Game Boy game that emulates a more advanced CPU
« Last post by Crow! on February 08, 2019, 05:01:15 PM »
There are indeed some emulators that are irresponsible and effectively enhance the capabilities of the simulated machine.  ZSNES is probably the most famous one in this regard; all lag that games experience completely disappears when played on that emulator.  The emulator I used is called BGB, and the romhacking / tool assisted speedrunning communities regard it as pretty accurate.  (Another popular emulator for Game Boy games, Virtual Boy Advance, is not.)

If you would like to test things out yourself, go right ahead, and let me know how it goes!  Here's a link to the RHDN entry for my hack (it got accepted yesterday):
http://www.romhacking.net/hacks/4351/
17
Well, the reason I ask about testing it on an actual Gameboy is because modern computers have tons of available memory and memory with a much higher hertz than the Gameboy. So even if your code is still within the memory limits of a Gameboy doesn't mean that it would work on an actual Gameboy.
This is irrelevant. Emulators emulate the exact environment of a given hardware setup. They're not perfect but for all intents and purposes they're accurate -- what the host's hardware configuration is has no bearing on the emulated environment.

I think Leeor would be less skeptical if it was proven that what you say works for the emulator, also works for the actual hardware of a Gameboy. Otherwise it is purely theoretical speculation.

My skepticism comes from knowing the limitations of the GameBoy... but Crow! has explained things in a way that I'm less skeptical. I'd like to see an assembly breakdown of the VM environment but I don't really have the time for it... basically saying it's emulating a higher bandwidth CPU is a bit of a stretch but from what I can tell it's doing some interesting things that could work on the 8bit CPU of the GameBoy.

So, basically what I'm trying to say is that if you say something far-fetched, then it is best to provide solid proof it actually works ... snip ...

He demonstrated how it could hypothetically works and knowing the hardware it might make sense. I would still like to see a disassembly of the code (assuming it's not obfuscated) and see if I can get an idea for it all.

Second, although the game boy itself has a paltry 8kB of RAM, the ROM of the cartridge can be much larger.

This. This right here is how so many games back on the NES/GameBoy/Etc. which had extremely limited resources could do things that the base hardware could never possibly do. It's a technique known as bank switching and on the NES they used what were called memory mapper chips (MMC). Nintendo provided the MMC1, MMC2, MMC3, MMC4, MMC5 and MMC6 (MMC3/6 [they're almost identical] is the most well known as it's used in Super Mario Bros. 3, it's what allows the static HUD at the bottom of the screen as well as vertical and horizontal scrolling at the same time, something the NES isn't capable of on its own).


That square chip at the top center of the PCB is the memory mapper chip.

The two large chips on the bottom are the Character ROM (graphics connected to the PPU chip in the NES) and Program ROM (connected to the CPU in the NES). This is what most NES games have. The small chip on the top left is the NES10 lockout chip (Nintendo's awful way of trying to prevent piracy). The last chip on the top right is additional RAM for use by the program. That's the interesting part -- this is the extra RAM that is built into the game's PCB that allows it to do way more than the NES would otherwise allow. Side note, HOLY SHIT is it slow! 100ns response time, yeeeeeeesh!

Anyway, GameBoy games are just as capable of using additional RAM chips like this. Hell, I wouldn't be surprised if they added an additional CPU core if they really needed it -- the SuperNES was well known for this via the SuperFX chip. It was basically an additional CPU that was dedicated to graphics manipulation and is what allowed for 3D graphics on the SuperNES (Sega's Virtua Processor was similar for the single game, Virtua Racing, that used it).

To sum up (for real this time), additional hardware on the cartridge would make this very possible. I'm just curious what hardware was on the PCB and how they mangaged the bank switching to make it work.
18
Well, the reason I ask about testing it on an actual Gameboy is because modern computers have tons of available memory and memory with a much higher hertz than the Gameboy. So even if your code is still within the memory limits of a Gameboy doesn't mean that it would work on an actual Gameboy.

I think Leeor would be less skeptical if it was proven that what you say works for the emulator, also works for the actual hardware of a Gameboy. Otherwise it is purely theoretical speculation.

Much like that whomafu (the guy never spelled it for me, but that is what it sounded like) that a kid told me about in 7th grade, that was a secret unit in the original starcraft (pre-brood war; basically it was supposed to be like the Lurker, but didn't have to unburrow to move). I tried to reproduce the steps they suggested to spawn the unit (gather 10,000 minerals and gas, get a hydralisk and an infested terran and then hit Shift+Alt+C to activate the hidden morph command) and I never could get it to spawn. If they had instead proven to me, by playing a game of StarCraft and spawning the creature, then I would have know it would work. I was skeptical then that the guy was scamming me, but that was the last time I saw the guy so never could ask him about it again. And google searches for something that isn't probably spelled right doesn't come up with anything either.

So, basically what I'm trying to say is that if you say something far-fetched, then it is best to provide solid proof it actually works otherwise you are going to be surrounded by a crowd of skeptics that think you are pulling their leg. Not saying you are, but it has been my experience that with far-fetched stuff (the whomafu wasn't the first or the last time I ran into far-fetched stuff) that the more far-fetched it sounds, the more likely it isn't true.
19
Computers & Programming General / Re: A Game Boy game that emulates a more advanced CPU
« Last post by Crow! on February 07, 2019, 02:38:00 AM »
I see two likely reasons for the 24-bit nature to be selected.  First, it allows math that balloons in size near the middle of a calculation - for example, there are a lot of percentages used in the game's combat math, so this allows a 16-bit integer to have a percentage taken by just multiplying it by the percentage then dividing by 100.

Second, although the game boy itself has a paltry 8kB of RAM, the ROM of the cartridge can be much larger.  FFL3 itself uses a 256kB ROM, which is divided into 16 banks of 16 kB, of which two are accessible at a given time.  Although the code I've touched didn't have to do this, the game in principle has to frequently jump between banks, so letting a 24-bit virtual machine handle bank switching whenever needed would allow them to act as if they could address anything in the ROM directly.

I don't have the hardware necessary to hook up my modified code to a physical game boy, but it runs fine on an emulator.  I use BGB as my game boy emulator for debugging purposes.
20
Interesting. So you've personally tested this out on an actual Game Boy?

I don't see why someone would target 24-bit architecture. Plus most of your own code is targeting 8-bits or 16-bits anyway, so it would make more sense to target 16-bit over 24-bit.

What value would there be to target 24-bit? I doubt a Gameboy had sufficient memory available or a powerful enough CPU to make it worthwhile to target a higher architecture than 16 bit.
Pages: 1 [2] 3 4 ... 10