News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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 - Geiger

Pages: [1] 2
1
Personal Projects / Re: FF4 Roguelikeifyer
« on: November 29, 2016, 01:49:41 pm »
The thing about the chest rarity is that there can only be a maximum of 256 chests among all the overworld maps. This is a technical limitation of the rom that is difficult to avoid, especially when I'm trying to use as much of the map space as I feasibly can.

An in-game dungeon randomizer was an idea I toyed with for Chrono Trigger.  While I would face many of the same technical limitations as yourself, it was technically feasible that I could create a random 'fake' chest.  It wouldn't be automatic, and there would be little to no long-term tracking of it.  Would work something like:

  • Paint a tile with a closed chest.
  • Make the tile solid.
  • Attach an interaction event to the tile.
    • Paint tile with open chest.
    • Play treasure sound.
    • Give item to player.
    • Display dialog.
    • Turn off object.

But then, Chrono Trigger is capable of some pretty advanced stuff, like self-modifying code.  I admit I don't know anything about FF4's event commands or memory usage, so this might be two or three orders of magnitude impossible.

2
Even as a 'normal-straight-consumer' programmer you *need* some math, for instance big O.

As a professional programmer for eleven years at three companies (the last six for a Fortune 500), I can tell you the amount of non-basic math I use on a regular basis quickly approaches zero.  All the stuff your professors in college (and high school?) tell you about how computer programming works does not seem to exist in the world of common programming.  Algorithms aren't a thing and code reviews are exceedingly rare.

3
Newcomer's Board / Re: Chrono Trigger Text Editor help
« on: August 30, 2012, 09:17:26 am »
I know Bisqwit had some utilities and other neat add-ons.

I do not know it to actually be true, but I have been told that the tools by Bisqwit do not work very well, which was why I added translation to Flux (I had previously been of a favorable impression).

Still, it would not hurt to try.  I seem to recall Bisqwit tools were specifically designed for non-English translations.  So if they work, I would expect them to have little problem with your special characters.

4
Programming / Re: Professional game company programming language?
« on: August 28, 2012, 03:14:59 pm »
I only have anecdotal evidence, but the C family seems to be the most popular.  Coding to the metal (ASM) is nearly unheard of these days (one of the reasons emulators for more recent systems actually work better than for older systems).  A lot of work is now done through scripting, tools, and middleware (and apparently is shifting ever more in this direction).

But then, there are the odd ones here and there.

5
Newcomer's Board / Re: Chrono Trigger Text Editor help
« on: August 27, 2012, 03:33:44 pm »
kringlur:  Just confirming what you already know.  Not suggesting you change anything.

so you know where you stand with Mono compatibility.

I also don't care if it runs on Mono.  I target Windows and use the features that best suit my program.  Other platforms are beyond the scope.  When the source for v4.0 gets released (provided I can ever get the bloody thing finished), someone else is welcome to port it to other platforms.

But I did check Moma out of curiosity.  Seems Mono does not support some portion of the parallel processing library nor type equality, oddly.  Definitely not interested in giving up the benefits of either of those.

6
Having actually done a bit of amateur game programming, you will need to know some calculus if you are writing the base 3D layer (not just linear algebra).  But typically, it is something you only need to be familiar enough with to figure out which formula to look up.  Back in my graphics course, I wrote a very basic version of the Ocarina of Time's shooting gallery mini-game.  I needed a formula from Calculus III to compute the position of a point on a sphere, for camera rotation.

If you stick to 2D, you probably will not need any calculus, but you may still need linear algebra if you get fancy with effects.

If you plan to do this professionally, you should know some calculus.  As much as your brain can handle.  (You can probably stop once you can compute the surface area of a saddle floating in space.)

Some basic physics will serve you well, but you probably do not need anything too advanced unless you are writing some sort of space simulator for NASA.

7
Newcomer's Board / Re: Chrono Trigger Text Editor help
« on: August 27, 2012, 10:14:53 am »
Unfortunately I tried using Temporal Flux just now and it crashes as soon as I try to open a rom. I can't even actually open the rom, it crashes with the browsing window still open. Probably it's because I'm running Crossover, I don't have a Windows.

Flux requires the .NET Framework to run.  To my knowledge, even Mono does not support all the features Flux uses, so it will pretty much only run on Windows.

8
Programming / Re: Temporal Flux Journal
« on: July 24, 2012, 10:12:12 am »
A couple of challenging things have popped up recently in this project.

I faced the difficult decision of breaking all of the plugins, twice.  The first one resulted from changes made to move the program more fully over to parallel processing.  Previously, there was a function call available to plugins that made use of window assets to post status messages.  But window assets are not multi-thread safe.  The function had to be reworked so that it dispatched messages to the prime thread which then consumed them to post the messages.  The change is not, unfortunately, transparent, but I was hopeful that I might be able to make it so later on.  Until the project-orientation got implemented.  The approach is so different that I do not think there is a way I could abstract it away so the plugins could continue to function as before.

And here, the plugins fold back in on me and affect my project.  I have implemented the most basic level of a project-oriented approach, but there is a lot more work to do.  From the application's and user's point of view, there is little reason I could not roll out this version and finish implementing features in a point release.  But the additional features will require still more changes from plugin authors.  Which means that I can either tell them their new plugins will only work for a couple of months until the point release, or I have to treat the entire project-orientation as a fixed solid unit that can't be broken down into smaller releases.

Also, the more work I do towards project-orientation, the more required features I see decompressing out of the idea.  For example, if I am going to properly facilitate free record association, it means I am also going to need to define creating a new record... of each type of record... what that blank record looks like... a dialog to select a new record type...

Currently, I stand at .23 DNFs.  Hopefully, that number won't reach 1 before I am able to get this done.

9
Is there a place where this is documented online?  Couldn't find this anywhere, even though significantly more intricate code/data like event sequences and map tiles have already been thoroughly investigated (I mean Temporal Flux is something that precious few other games will -ever- get).  It really did surprise me :/.

My team focused on things no other editor could do, and major subsystems.  A lot of common stuff has not been added until more recent versions, if at all.  For example, Treasure editing was only added after a poll listed it as the most wanted feature.

If something is not documented in my offsets guide, it likely does not exist in any formal documentation.

As for Flux being a rare item, one of my goals with the WIP version rewrite is to provide a base code layer that other people can use for other games.  A backbone that does the heavy lifting.  But only time will tell if it accomplishes that goal and I still have to finish the bloody thing first.

This is some fine cryptanalysis you have here.  Keep at it.

10
If you specifically want to use one of the two games, it really depends on what you want to focus on.  Final Fantasy VI has tools more readily available for the battle side of things (spells, items, effects, monster sprites, etc) whereas Chrono Trigger is more tightly focused on level-building (maps, events, strings, etc.).  Both games have tools available in other areas, but these are their strengths.

Final Fantasy VI also seems to have a lot more dedicated hackers available, which might make it easier to figure stuff out.

11
Aaaahh...so you open up the location map where the text is encountered, record the event number for that map, then go to location events and type that in for 'packet number' and you can access the dialogue you want.  Thanks for the heads up, now I can edit that particular set of strings with either of them.

There is no reason you should want an older copy of Temporal Flux.  Especially not one so old that the dialogue text is still in the string editor.  All features in later versions are additive improvements.  None have been removed, though they may be in different places.  Also, older Fluxes are not forward compatible with newer ones.  Once you have edited a piece of dialogue with the newer edition, the older one will have no idea where it is (and may even crash).

With regard to the actual editing, you do not need to get the packet number separately, unless you want it for future use.  When you find the location in question, click on the blue Event label.  It will open up the associated event.  All blue labels work in a similar manner.

12
Programming / Re: Temporal Flux Journal
« on: March 27, 2012, 02:08:01 pm »
It is definitely NTFS, and I can only imagine it happened accidentally while trying to click something away.  It is not something I would have done purposely.

Encryption is not the only reason why you will want to check your project.  Maybe external source did not get transferred.  Maybe a necessary tool is missing.  Maybe tool or system configuration is different between the two machines.  This is something that should always be checked.

Unfortunately, I was in a bit of a hurry and needed to just grab my external drive.

13
Programming / Re: Temporal Flux Journal
« on: March 27, 2012, 12:01:23 am »
An interesting problem has popped up for me.

Generally speaking, if you are going to move your project from one computer to another and won't be back to the first one in awhile, make sure it works on the one you'll have.

Somehow, my primary project file has gotten encrypted.  I cannot even touch the file, let alone compile or even open the project.  And, for reasons I do not understand, it is keyed to only decrypt on the original computer.

I... have no idea.

14
looks like a bug in the ROM caused by an older TF version.

Unlikely (though not impossible).  Most bugs in patches released in the last 5+ years come from other utilities.  When someone bothers to trackback, anyway.  Most error reports are "stuff's broken".

If you can send me an email with Flux version and a link or attachment of the patch, I will look into what is breaking when I have time.

15
Programming / Re: Temporal Flux Journal
« on: March 08, 2012, 01:50:34 pm »
For myself, I attribute it to evolution of my programming ability. I finally gained enough experience to start to better recognize flaws in my software design and identify better approaches. I started to see the big picture instead of the box I was typically in. I know nothing of your abilities, but wonder if it has not been much of the same for you?

Sort of, but not exactly.  I have been a professional programmer for eleven years, and eighteen years total experience.  That doesn't take into account all the extra hours I spend on hobby projects.  Of course, you never stop learning, but my skills are pretty sharp.

In my case, its more a matter of how much time I have spent on this specific project.  Even with my current skills, by no means could I program Temporal Flux as it is today if I just started on the project.  It would probably look a bit better than v1.00 did, but it probably wouldn't be even as good as v2.00, let alone the current WIP stuff.  As you work on a project, you come up with solutions for your current issues.  And then once those are in place, you can take a step back and look for even better ways to improve it.  And so on.  Its an evolutionary process.

And its not just the project experience, but also the tools available to make things happen.  If I was still working with the .NET Framework 1.1, I wouldn't be able to do a lot of the stuff I am using in this version, or even the last couple of them.  (Oddly enough, some of the tools have gotten less useful over time, so I am still using some 1.1 stuff here and there.)  And in turn, the new solutions these tools enable push me to think about still more solutions for other issues.

16
Programming / Re: Temporal Flux Journal
« on: March 08, 2012, 10:13:12 am »
The next version of Temporal Flux will be a project-based system.  Up until now, it has been ROM based.

The difference between them is that in the latter, the ROM is king.  Everything revolves entirely around the ROM.  It is where you get and store the data.  Information is primarily kept the way it appears in the ROM.  If you want to store meta-data, you will need to find some way to attach it to the data you are keeping in the ROM.

In the former, the ROM only serves 1.5 purposes.  It is the original source of data (maybe) and it is where you store the final version of the data.  All those other concerns drop away.  Once you have done the initial data retrieval from the ROM (if you don't create everything whole cloth), it will always come from an external source file.  Meta-data can be stored directly in the source file.  Information can be abstracted as much as you want and stored that way.  The data is modified and saved to the source files.  And finally, everything will be regenerated and saved back to the ROM.  In a sense, everything becomes a lot easier to work with and accomplish.

But abstracting away from the entire ROM is very complicated.  Having meta-data and significant data abstraction requires that I have a way to process them and convert them back to something the ROM actually recognizes.  If the data is organized in an unusual fashion, I need to figure out how to store the information to file and then reliably recreate that organization the next time it is opened.  It will mean further changes, like not having all of the records open at once.  Which, in turn, means I have to come up with a new means to calculate free space since I cannot just run down the record list.  And it continues on from there.

Some (most) of that will not be in the next version though.  I don't want to take another four years before I release.  For now, it requires orienting the program around a project, for which the ROM will merely be a setting.  I need to figure out what the bare minimum for that entails.  The ROM needs to be fully dethroned, and I need to be able to grow the rest of the features in a natural way as things continue going forward.

It will be a challenge.

17
ROM Hacking Discussion / Re: Open Source ROM Hacking Projects
« on: March 04, 2012, 12:17:24 am »
My data information has always been freely available.  My compression library has had available source since nearly the beginning.  An example plugin project actually has some portion of Temporal Flux's source in it.  TF v4.00 will have its source released along-side it.

But none of my projects will ever be "open".  Open implies multiple programmers.  After dealing with the horrible atrocity that is the Snes9x code base, I will never have that on my projects.  Awful programming aside, I also enjoy being a unilateral dictator on the direction of the source code.  If I had to deal with a committee, I probably would never have gotten the chance to do this massive code rewrite (which I suppose might be a good thing from certain points of view).

I don't necessarily oppose openness, its just not for me. There's also the fact that I program for a living.  Most programmers don't just give their stuff away.  It doesn't promote keeping a job for very long.

18
Programming / Re: Temporal Flux Journal
« on: February 25, 2012, 12:26:20 pm »
Incidentally, how well do you document what you're working on?

I have a bug tracker set up, and I keep major changes on my WIP list, which eventually becomes the version list.  I also use source control.

I typically use the bug tracker for things that other people report.  Most notably, it was busiest when I had a beta team.  While I don't use it as much now, I still keep track of long term goals and ideas that won't be tackled anytime soon.  I mostly use a todo list in a local file for things I find.  And usually, if I find a bug and fix it a couple hours later, I don't bother to document it.

The WIP list is mostly for other people to know what sort of changes I have made.  But I do occasionally make references to it, if I want to know the timeframe for when something was added.  The WIP list is mostly constructed from things I finish on my todo list, though usually condensed a bit.  In that sense, it also serves as a list of accomplishments which will give a small morale boost when I look at it.

The primary type of source control I used throughout the years was just to copy all of the code into a new directory whenever I started a new version.  This will suffice for smaller projects, but is hardly optimal.  Fortunately, a few years ago a friend clued me into Perforce.  Its a bit difficult to setup and use compared to most major commercial source control, but its free (2 users), fully featured, and works pretty well once everything is going.  If you have a computer you can use as a server, understand how (real) source control works, and have a little technical know-how, I strongly recommend it.

19
Programming / Re: Temporal Flux Journal
« on: February 24, 2012, 07:48:48 pm »
No real insight this time.  Just a warning that some bugs are bad enough to end projects, if you don't have the willpower to see it all the way through to the end.

For nearly a year now, I've been hunting a bug in the Overworld Exits.  They are suppose to synchronize with the Overworld Event code (some exits can activate events).  And the code generally looked correct to accomplish this.  And sometimes it even did, in a very limited manner.  But the vast majority of the time, they just wouldn't work.

The number of bugs I've found and fixed in this hunt would be enough to warrant their own minor version release if I weren't in the middle of a rewrite.  I haven't kept track of them all, but I'd estimate between two and three dozen.  Every time I thought I was getting close, I'd hit another bug, another detour, or another subsystem to rewrite.  There are a number of times I felt like saying "To Hell with it!" and ripping synchronization out of this one subsystem just so I could move on to one of the other dozen major items on my list.  If I were much earlier on in the project's life, I might have just thrown my hands up into the air and moved on entirely.

I have debugged stuff into the Windows kernel that I did not have source for easier than this.  This is easily the worst bug I have ever had to deal with in the entire nine years of this project, and possibly in my entire programming career.

Or at least it was.  I released the first closed Alpha of what will eventually become Temporal Flux v4.00 a couple of hours ago.  Only a month late.

20
Programming / Re: Snes 9x Documentation
« on: February 24, 2012, 07:30:49 pm »
Not really, no.  The only documentation that really exists is on how the real SNES handles stuff.  In my experience, the only code the team really knows all that well is what they wrote themselves (as in, each individual really only understands the piece of code they wrote personally).  Anything written by someone no longer on the team might as well be a black box.  I was actually the official windows port author for several months and no release ever saw the light of day under my watch largely because of this.  (Which is to say, the windows port was incredibly broken, and no one could tell me how the underlying stuff was suppose to be communicated with.)

Still, you might try the official forums.  One of them is purposed for development.  Someone there might be able to help you.  (Though there seemed to be a lot of tumbleweeds last I checked.)

Pages: [1] 2