Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Computers & Programming General / Re: A Game Boy game that emulates a more advanced CPU
« Last post by Crow! on February 06, 2019, 02:06:38 PM »
The syntax for the script targeting the 24-bit interpreter works as follows:

First, an operator is supplied with a byte in the format aaabbbbb. bbbbb is the command to be executed.  Commands that cause math to occur look at aaa to decide what sort of argument will follow the command.  Other commands are things like "jump to subroutine" which always takes a 16 bit argument, or "return from subroutine", which doesn't take any argument.

The "return from subroutine" command 06 causes the game to pop an item from a stack of 16-bit addresses whose contents build up from address cc11, with the address of the top of the stack being tracked in cc0f-cc10.

When entering a command which does math, commands change meaning until "end of current expression" 1f is found.  This second set of commands (which I've been calling operators) also follow a aaabbbbb format, with aaa having the same meaning as it does in the previous set of commands.

Within an expression, the game uses addresses cc05-cc07 as a 24-bit accumulator, while cc08-cc0a are in charge of receiving data from the argument.  The interpreter will separate the data type from the operator's id, call a subroutine to grab the argument based on the data type, then call a subroutine to perform the operation requested with the two numbers now loaded.

The data types (aaa part of the commands listed above) appear to be as follows:
Quote
00 XX: Direct page.  Points to c9XX as an 8 bit number.
20 XX: Direct page. Points to c9XX as a 16 bit number.
60 XX: Indirect page.  Points to the data that the 16 bit address stored in c9XX itself points to.
c0 XX: Literal.  Loads the number XX from the script.
e0 XX YY: Literal.  Loads the number YYXX from the script as a 16 bit number.

Here are data types I haven't seen in action but that I suspect exist:
40 XX: Indirect page.  Points to the data in the direct page that the 8 bit address stored in c9XX points to.
80, a0: should exist, but I have no knowledge of what they do.  Maybe for 24 bit data?  The virtual machine is set up to handle that but the code I've touched hasn't needed it.

Command 03, which is "call a GB-native code subroutine" is used sparingly.  It's implementation is pretty cool, though - since the game boy's only CALL opcodes can only take a literal, but the game wants to use to the routine specified by the script, the game instead pushes the intended return address to the stack then jumps using JP (HL).


Here's an example of code I've written:
Code: [Select]
20 47 		target c947 as a 16-bit number.  This RAM seems to be unused.
ec 80 dc load the number dc80 - this is the address of a timer for animation; it cycles from 0 to f constantly.  I'm going to use it like an RNG, which is probably OK because its current state depends on the exact frame when the player cleared the last text box.
1f save it
00 95 target c995 as a 8-bit number
6c 47 load the thing pointed to by c947.  Notice I had to first point at the data and then use it; if there is a "load data from the following 16-bit address" data type, I haven't seen it.
c5 03 and with 03
1f save
05 YY YY call my "make sure robots have stuff" subroutine
05 cf 5d call subroutine 5dcf (does all the heavy lifting; I'm going to run out of space in this section of the ROM soon so continue code over there.)
02 e7 58 jump to 58e7 (i.e. continue on with the game's usual script here)

Inside subroutine 5dcf, here's a conditional where I use my "random" number:
61 47 Begin a conditional, with the left hand side of that conditional contained in the address c947 itself points to.
cf 02 0f seems to be the "<=" operator; a subtraction is performed immediately, and the game marks that 0f was the most recently used comparer in cc03.  cf, then, is "compare with the number provided here".
1f Evaluate the expression.  If it was true, do the next command.  Otherwise, skip that command.
02 78 3f Jump to 3f78, where I handle turning the character into a robot.

The way this system handles data is the main reason I call it a virtual machine rather than a script engine - it has a direct page, it allows indirect indexing, etc, making coding for it feel far more like ASM than like BASIC or whatever.  It maintains a stack pointer and an execution pointer, but doesn't seem to have the additional indexing registers processors generally do.
22
Outpost 2 Add On Missions / Re: Using GitHub for Outpost 2 mission development
« Last post by leeor_net on February 06, 2019, 10:21:57 AM »
Agreed that we could use a common tag. Hopefully something short and easy to remember. I'd prefer to avoid hyphens if possible. I would like a setup where people can design their own levels without needing to be a part of OPU. I'd like to preserve the self-serve nature of GitHub.

Forking me thinks.
23
Outpost 2 Add On Missions / Re: Using GitHub for Outpost 2 mission development
« Last post by Hooman on February 06, 2019, 01:31:16 AM »
This actually looks like a good way to organize the projects. Rather than have a level include every library as a separate submodule, it can just include the SDK project, which wraps everything together, and with consistent version numbers. I rather like this solution.



I'm not too sure what the build matrix stuff is about. I don't think you actually need that for what you are doing. Generally a build matrix is used when you're compiling for multiple architectures, or have different configurations of the same project that you want to build in parallel. I don't think you need that here. All you need is dependencies to be specified so all projects are built together in the proper order (some of which may be in parallel, but they're different projects). In that case, they all build in a single job, rather than having a matrix of jobs.



Agreed that we could use a common tag. Hopefully something short and easy to remember. I'd prefer to avoid hyphens if possible. I would like a setup where people can design their own levels without needing to be a part of OPU. I'd like to preserve the self-serve nature of GitHub.
24
Outpost 2 Update / Re: Updates for Outpost 2 1.3.8
« Last post by Hooman on February 06, 2019, 01:17:58 AM »
I've encountered similar with OllyDbg. In the case of OllyDbg, when I loaded a LevelDLL, it first loaded a DllHost.exe, which was basically just a dummy executable used to create the process and address space to host the DLL being debugged. The problem was, the dummy EXE was at the preferred (and MSVC default) base address used by Outpost2.exe. When the levels made references to Outpost2.exe (as they do to call the exported methods used to interact with the game), it would cause Outpost2.exe to be loaded into the address space. However, the preferred base address was already taken, so it was relocated to another address.

The problem with NetFix, and other OP2Internal (formerly ForcedExports) projects, is they relied on having a known fixed base address for Outpost2.exe. Or rather, they relied on having a fixed relative offset between the Outpost2.exe module's base address and it's own module's base address. The two could be relocated independently. In NetFix, there is a safety check that causes it to abort loading with a failure code if the Outpost2.exe module is not loaded at its expected address.

I'm guessing something similar happened with the debugger you are using.

The workaround I used, was to have the debugger load Outpost2.exe first, and then load the level and debug it that way.

More long term, I'd like to change how OP2Internal works so modules can be independently relocated (which is how Windows works), rather than assume nothing will ever be relocated.
25
Computers & Programming General / Re: A Game Boy game that emulates a more advanced CPU
« Last post by Hooman on February 06, 2019, 01:07:10 AM »
Lol, Leeor the skeptic.

My first thought was they wanted to re-use existing code that was designed for a different architecture. Rather than re-write, just run it under an emulator.

Though I do get what you're saying Leeor. The Game Boy isn't exactly very high powered, and virtual machines can add a lot of overhead.

@Crow!, I'd be curious if you'd post any details on what exactly you're working on. Is there any sample code you could share? Maybe a screenshot of what you're doing?


Edit: Had to add a link to this:
XKCD #285: Wikipedian Protester
 :P
26
*citation needed

I'm somewhat skeptical that a GameBoy has the power to run a virtual machine of a 24-bit processor on an 8-bit architecture and still be performant in any sort of way. Even with ingenious coding techniques that seems like a virtual (get it?? eh eh? :D ) impossibility.

On the same token I've seen some really impressive things done by programmers that are far smarter than I am so I'm skeptical but not incredulous.
27
Computers & Programming General / A Game Boy game that emulates a more advanced CPU
« Last post by Crow! on February 05, 2019, 06:20:12 PM »
One of the things I've been doing for the past couple years is making randomizing ROM hacks for old RPGs.  Recently, I started working on Final Fantasy Legend III, a late Game Boy game.  The Game Boy's processor is somewhere between a 8080 and a Z80, but apparently the programmers on the team (who were evidently WAY better at their jobs than the guys who worked on FFIV, let me tell you) didn't much care to program in that environment.  So, they programmed a 24-bit virtual machine, and wrote their game in code that targets that better "CPU" instead.

"Opcodes" for this "machine" reserve 3 bits to describe what sort of argument it will be provided, with options like "16-bit literal" and "8-bit indirect direct page." For opcodes that require an input number, subsequent commands come from a different set of infix operators, including stuff like "multiply" (not in the actual CPU's instruction set, btw) and "bitwise AND". The program also allows subroutine calls, and maintains a stack to facilitate returning to the caller.

In the end, when I changed the rules of the game in FFL3 Lunacy, I actually didn't code a single thing that could run on the Game Boy's processor.  I still did the usual code injection, find unused RAM to work with, etc. shenanigans that I've done with other ASM projects, but I had the privilege to target this more interesting and convenient virtual machine since that was what the game was actually running.
28
Updated the game to V26! Now, major changes are listed in a Changelog, viewed from ingame from the main menu.

Also created a monthly recap of Dec/Jan for anyone interested = https://www.reddit.com/r/roguelikes/comments/an969c/monthly_update_empires_of_eradia_the_cataclysm_of/
29
Outpost 2 Add On Missions / Re: Using GitHub for Outpost 2 mission development
« Last post by leeor_net on February 04, 2019, 06:05:25 PM »
This has pros and cons. The pro is that you don't have multiple copies of Outpost2DLL in the same solution (one for HFL, one for OP2Helper, and one for the custom mission itself). The con is that you cannot download OP2Helper standalone and compile it. I think another pro is that all projects will use the same version of Outpost2DLL. IE, you don't have to worry about HFL being on an earlier version of Outpost2DLL than OP2Helper (assuming we ever update Outpost2DLL again). If others want to use OP2MissionSDK to develop scenarios, we can discuss other architectures.

Sounds to me like the pros far outweigh the cons. This is the sort of thing I wanted to do in the past... it lead to an argument about directory structure and "This is how it's always been done" so I kinda left it alone. That was years ago though so either way I think this is exactly the direction we should be going in.

I was going to setup an automated build as part of OP2MissionSDK that built HFL, OP2Helper, and Outpost2DLL. Apparently you have to create a matrix or something with appveyor and I gave up for the time being. As an artifact of this research, Outpost2DLL has an automated build in OP2MissionSDK.


We may want to encourage a specific GitHub tag for Outpost 2 missions. Maybe outpost-2-mission? This would make finding missions easier in the event that someone develops a mission and doesn't want to cede control of it over to Outpost Universe.

Acceptable to me.

I haven't pushed this scenario to Outpost Universe. Partly due to embarrassment. I generally right mildly substandard code. But in scenarios I write plain awful code because I treat it as a script hybrid and don't plan to reuse it. (Except I end up wholesale pasting sections from old scenarios for new scenarios).

Mission code doesn't have to be beautiful, it doesn't even have to be good... really it just needs to work. I'd say push it so we can have a modern example of a working mission using the current code base. Changes/cleanup/grooming can be done after the fact. :D

Besides, I've written some real stinkers myself. Just take a look at the OPHD code base... there are parts of it that wish I hadn't done the way I did... but they work until they can be refactored. So don't feel bad... we're all human... and we write shitty code... with bugs!
30
Outpost 2 Add On Missions / Using GitHub for Outpost 2 mission development
« Last post by Vagabond on February 03, 2019, 06:55:07 PM »
I've been playing with GitHub for Outpost 2 mission generation.

https://github.com/OutpostUniverse/OP2MissionSDK

https://github.com/Brett208/OP2MissionYukonTrail

OP2MissionSDK is a container for the other required submodules. Currently, HFL and OP2Helper do not contain Outpost2DLL as submodules in themselves. So if you were to download either one, you would not be able to compile. If you download OP2MisisonSDK, the 3 projects exist in the same folder structure as they do on the SVN repository. So they will all compile fine.

This has pros and cons. The pro is that you don't have multiple copies of Outpost2DLL in the same solution (one for HFL, one for OP2Helper, and one for the custom mission itself). The con is that you cannot download OP2Helper standalone and compile it. I think another pro is that all projects will use the same version of Outpost2DLL. IE, you don't have to worry about HFL being on an earlier version of Outpost2DLL than OP2Helper (assuming we ever update Outpost2DLL again). If others want to use OP2MissionSDK to develop scenarios, we can discuss other architectures.

I was going to setup an automated build as part of OP2MissionSDK that built HFL, OP2Helper, and Outpost2DLL. Apparently you have to create a matrix or something with appveyor and I gave up for the time being. As an artifact of this research, Outpost2DLL has an automated build in OP2MissionSDK.

I also stuffed odasl into OP2MissionSDK, so you can create custom modal dialog boxes for custom colony games.

We may want to encourage a specific GitHub tag for Outpost 2 missions. Maybe outpost-2-mission? This would make finding missions easier in the event that someone develops a mission and doesn't want to cede control of it over to Outpost Universe.

I haven't pushed this scenario to Outpost Universe. Partly due to embarrassment. I generally right mildly substandard code. But in scenarios I write plain awful code because I treat it as a script hybrid and don't plan to reuse it. (Except I end up wholesale pasting sections from old scenarios for new scenarios).
Pages: 1 2 [3] 4 5 ... 10