Loading configuration from a text file

[rainwarrior]

No, I'm talking about actually manipulating the game, like changing the variable running speed, which is conveniently located in a textfile (somehow. Does the game actually parse the textfile to find something like "runspeed:" in ASCII? Why not just make it some kind of variable before compiling? Creating something that reads a textfile is more CPU intensive and just more hassle to program

You're suggesting that they need to shave 10 milliseconds of text parsing off the startup time (why?) by either removing this accessible debug feature, writing a specialized tool to put it into binary format, or requiring someone to recompile from source? Why do you think text parsing is more "hassle" to program than binary parsing? (It's not. For most professional programmers it is a bread and butter staple.)

It's almost like they want people to mess with the game.

Specifically, they want people who are working on the game to be able to change things about it without having to compile it from source. A game like this probably takes a few minutes to compile, not to mention that compilers are expensive and anyone who isn't a programmer probably isn't set up with one (and may have never used one before). How would that be an advantage over editing a number in a text file that immediately takes effect whenever you run the game?

[Drew Sebastino]

You're suggesting that they need to shave 10 milliseconds of text parsing off the startup time

Wait, only at startup time? I guess they just keep the value in RAM? (even though it doesn't change, but still, only having to read the list once is different than having to do it every time you want that value).

Why do you think text parsing is more "hassle" to program than binary parsing?

How is it not? Just writing "LDA #RunSpeed" or "MOV AX, RunSpeed" is much easier than something that searches a whole area of memory, constantly checking values for "Runspeed:" (It would have too look for "R", and the "u" and then "n" and so on and so forth. If it encounters one wrong letter, than it starts over again, looking for "R").

...Oh, wait...

[tepples]

You're suggesting that they need to shave 10 milliseconds of text parsing off the startup time

Wait, only at startup time? I guess they just keep the value in RAM? (even though it doesn't change, but still, only having to read the list once is different than having to do it every time you want that value).

Without an execute-in-place ROM, Wii U has to keep everything in RAM. The only Nintendo platforms with execute-in-place ROM are NES, Super NES, Game Boy, Virtual Boy, Game Boy Color, and Game Boy Advance. The rest use either SSDs (N64, DS, 3DS) or optical discs (GameCube, Wii, Wii U), and these have to keep the working set of code, static data, and game state in RAM at all times.

[rainwarrior]

How is it not? Just writing "LDA #RunSpeed" or "MOV AX, RunSpeed" is much easier than something that searches a whole area of memory, constantly checking values for "Runspeed:" (It would have too look for "R", and the "u" and then "n" and so on and so forth. If it encounters one wrong letter, than it starts over again, looking for "R").

Why on earth would you assume that a program is re-parsing a text file every frame? The text file doesn't change after it's loaded, so there is no reason to reparse it.

Most high level languages have a lot of ready-made text parsing libraries available, and most of them also have a lot of text parsing utilities built into the language.

In NSFPlay, getting a value from the config file looks something like:

Code: Select all

runspeed = CONFIG["runspeed"];

No, not a hassle at all. Yes, it's "slow" code that you shouldn't run in an inner loop, but this makes zero difference at startup, and there is a lot to gain by having a human readable/editable config file.

[Drew Sebastino]

Why on earth would you assume that a program is re-parsing a text file every frame?

because...

execute-in-place ROM

But obviously, the Wii U doesn't have this, nor are any of the games (at least I highly assume) written in assembly.

Today is not my day...


I'm just curious though, but what are the point in SSDs on a cartridge system?

[tepples]

what are the point in SSDs on a cartridge system?

Sometimes structuring solid-state memory as a disk is more efficient than structuring it as execute-in-place. For one thing, it takes fewer pins, and for another, it lets the system use cheaper, slower, block-organized memories such as NAND flash. It's sort of like the difference between SRAM and DRAM, if you know what that is, except an SSD sits even below DRAM on the memory hierarchy. That's why the GBA SuperCard, GBA M3 Perfect, NES PowerPak, and SNES PowerPak copy the game out of a CF or SD card into a bunch of RAM before running it.

[Drew Sebastino]

So basically, you're telling me the only advantage it has is that it's cheaper? Also, I've never really known what a cache is (like the N64 texture cache). It seems just like a smaller, but faster, chunk of ram. Price aside, would it be possible to just have a very large cache and no ram, or does the cache have to be small for performance purposes for whatever reason?

[tepples]

In general, the larger a memory is, the slower and more expensive it is.

[Drew Sebastino]

Is the fact that it's slow directly related to the fact that it's big, (like some sort of physical limitation) or is it more like it's big, and we don't want to spend too much money, so it will be slow to be more cost effective?

[tepples]

Both.

More memory cells means more word lines and bit lines to address it, which means more propagation delays to access it. This is why caches are split into multiple levels (L1 vs. L2), as I mentioned in another post. The semiconductor fabrication processes to make processors and memory also differ slightly, making it more expensive to put memory on the same die as the processor. Finally, the innermost cache levels are SRAM, while main memory is usually DRAM, and SRAM occupies about four times as much space on a die (that is, four times as much money) as an equivalent amount of DRAM.