[Open]Launch Another .BIN File (And Pass Parameters?)


#1

Given the filename, I am assuming launching another .BIN file from the SD card within my game would be easy, right? I was wondering if there is a way to do it and pass parameters or some kind of data. Is there a way to do this? Do we need to pass data through RAM? Or is that cleared when loading another game?

If launching another game or launching another game with parameters is possible, what would that code look like?


#2

yes it is possible

the sd loader passes the filename through eeprom


#3

Can you show me the few lines of code (or psuedocode) that I would need? How would it pass other data? EEPROM, or is there a better method?


#4

I have duplicated the EEPROM class of the Arduino for simplicity and direct compatibility.
The bare minimum is simply

EEPROM.write(addr, val);   //write byte (unsigned char) val to addr
val = EEPROM.read(addr); // read a byte from addr

And there’s a lot more that can be done as well:

https://os.mbed.com/users/Pokitto/code/PokittoLib/file/fa6899411a24/POKITTO_HW/PokittoEEPROM.h/


#5

Is this the best way to pass params/data to another .BIN file? I want to pass about 20~30 bytes of data.


#6

It is a pretty bombproof way yes. For your own safety, do not use addr=0, because the loader is not finalized and it uses that area. Use something like addr=0xFF instead


#7

Well, since there are no standards to EEPROM usage, I would be afraid to overwrite someone’s savedata from some other game.


#8

Don’t worry about it yet. We already have that situation and it needs to be fixed in any case. Better just continue development and then align when we have it sorted out.


#9

Alright, I guess I will do that. What is the best way to Programmically launch another game?


#10

Thats actually a question I have not considered to be honest. Its easily fixable, but I need to add the hooks to do so into the sd loader

in pseudocode it would go like this:

  • check if SD loader is present
  • check SD card is readable and contains the file you want to launch
  • write filename to EEPROM
  • write parameters to EEPROM
  • jump to a hook in the SD loader

All of this would be automated into a single function of course.

in the style of

game.jumpToProgram(“foobar.bin”,parameterlist[0],parameters.length);


#11

Do we have this part finished?


#12

Thats exactly the part that needs to be added. Its simple stuff but needs to be added to the loader

EDIT: its basically just another entry point to the SD loader, that does not open a file list window (as in default entry point)


#13

:joy: I have designes my TCG to revolve around this functionality in order to fit all the features I want.

How long will it take to load the other game? I am assuming since it will go through the SD loader thingy, it will take the same amount of time as loading a game from the SD loader normally, which is a lil’ slow at the moment.


#14

Why? Can’t the core game mechanism fit?


#15

I second @jonne’s “Why?”.

This sounds like an X-Y problem to me.


#16

The “Why” is that I am not sure it will all fit. It needs to include good AI as well as gameplay mechanics. If I do not separate them out, I will have to have all AI players built into the same file, which will bloat it up. I think separating the files out will allow me to give different AI’s drastically seperate play styles.


#17

Why not just develop a system of bytecode to drive the AI?

See here for a good example of how to approach that.

You designed a language once, I can’t imagine bytecode would be beyond your capabilities.


#18

Would the AI byte code files be stored in separate files? That would definitely work, but the bytecode interpreter would still have to be developed. Doesn’t seem like there will be a quick way to tackle this problem. :stuck_out_tongue:


#19

Sure.
That’s the beauty of bytecode, it’s just a stream of bytes so you can throw it anywhere.[quote=“crait, post:18, topic:663”]
That would definitely work, but the bytecode interpreter would still have to be developed. Doesn’t seem like there will be a quick way to tackle this problem.
[/quote]

It’s not too hard to make one depending on how complex your existing interface is.
Like the thread says you can have instructions like “push own card health”, “push enemy card health”, “less than”, “if true jump here”.

Granted it takes time, but at least it means you don’t need to hook the SD card to swap actual machine code out.


#20

Ahh, yeah, GOTO would be very powerful in this situation, actually.