It is currently Wed Dec 13, 2017 8:10 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Sat Sep 12, 2015 8:13 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
In this post, Espozo wrote:
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.)

Espozo wrote:
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?


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 8:47 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
rainwarrior wrote:
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).

rainwarrior wrote:
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... :oops: :oops: :oops:


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 9:24 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19338
Location: NE Indiana, USA (NTSC)
Espozo wrote:
rainwarrior wrote:
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.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 9:28 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5893
Location: Canada
Espozo wrote:
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:
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.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 9:53 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
rainwarrior wrote:
Why on earth would you assume that a program is re-parsing a text file every frame?

because...

tepples wrote:
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... :oops:


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


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 10:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19338
Location: NE Indiana, USA (NTSC)
Espozo wrote:
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.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 10:47 am 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
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?


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 12:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19338
Location: NE Indiana, USA (NTSC)
In general, the larger a memory is, the slower and more expensive it is.


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 12:37 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
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?


Top
 Profile  
 
PostPosted: Sat Sep 12, 2015 12:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19338
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group