Ok good good to know and stick with using that.
Sorry about that. With the devkit delays, I kind of let me distract and work on other projects.
2 Likes
Sorry, that wasn’t meant to be a dig at anyone. As you say, without the devkits most of us turned our attention to other things. @Vampirics and I have been working on a game that will fit into the standard Arduboy (shock, horror!).
3 Likes
Some example code would be useful for me too. That way I’d only have to implement the important flash commands in the emulator.
3 Likes
Important to remember that this project is intended to be worked on at whatever pace you feel like. There is really no pressure here other than if you are interested to work on it.
It’s going to take a long time still, the key is to focus on the end result. The dev kits getting sent out will help. After those are all out, I’ll focus on trying to compile and come up with a guide and highlight some example code.
There are still a lot of Arduboys still in stock that need to sell before I can launch a new campaign anyways.
3 Likes
we’ve just plowed forward with the “make a giant sketch” approach. there are (lots) of risks with this approach, but I’m not too worried. The main risk is once converted to the paged approach, will the code itself fit in 28k?
1 Like
If your primarily focusing on just adding content then it should probably still fit. I don’t know if there is an easy way to strip out all of your constants and then see what your code compiles to.
1 Like
We are adding quite a bit of new logic too. I think it will fit as 28kb is a lot of code, and if it just doesn’t we can cut low priority features if we must.
What is the overall roadmap for FX once the dev kits ship? @2bitcrook and I have put a lot of work into the new Tackle Box. I’m currently blocked as it seems my ProjectABE hack is not working beyond 64kb, but I plan to debug that a bit when I get a chance.
I think we need the dev kit, @Mr.Blinky’s library, and ideally ProjectABE with FX support to really get the game across the line.
I think a more well defined road map on what to expect with FX would be helpful, @bateske . To be totally honest I’ve got a small worry all this work will be for naught.
3 Likes
So far only way to work on FX Dev seems to strip down all graphics ( since they will all be on the FX chip) and work on the gameplay and logic only, but even this way it’s not optimal. And we run out of ways to test everything. I have faith that this will all be possible. Just need more info about how it actually works and the actual Dev kits.
@Mr.Blinky am I right in thinking that having music stored on the chip would be possible the same way we will use it for graphics? A full fledge soundtrack for a game might be possible with this.
Another thing I was thinking about was if it would be possible to actually flash another hex while in game… Which would basically be like loading a multipart game? That could enable us to make huge games, like each part of a map could be an individual hex, would just need to reload the save and continue from that point… But would wear the memory faster I guess…
Anything stored as a CONST can be moved over the the external memory so yes it just becomes a question of leaving available ram so you can move stuff in and out as needed.
But yes I think the method that’s being used to just code assuming the resources can be added later is the only real way to go until we have an example sketch, hopefully having the developer kits to people will give them a chance to test stuff out.
And yes, having it re-flash a second hex as like a second chapter is possible and actually something I was thinking would be pretty cool. I don’t really think wearing out the flash is any more of a concern than if you were worried about wearing out an SD card. I’ve seen examples of a million writes on these kinds of hardware before there is any problem. And in order to hit these numbers sketches are made to constantly abuse the writes as fast as possible and it still takes like a solid week of running it.
1 Like
Think of the chip as off-board progmem.
Although whether or not it’s as fast as progmem, I have no idea.
That’s pretty much what @filmote did with Lode Runner.
Though by storing levels externally, that probably wouldn’t be needed anymore.
That sort of thing would only be needed if it was the actual code that you needed to swap out (since presumably the flash chip can’t contain executable code).
The idea I had for a multi hex game would be where the gameplay changes significantly. Like chocobo racing in FF7. Does something like that fit the scope of an Arduboy game? Maybe not but it does enable it.
I sort of always had this fantasy where like a dozen different games of different gameplay types all feature the same character and follow consistent story.
I guess this is, again, effectively how minigames are handled in AAA titles. But it would be a bit unique to have the entire game made up of minigames with very small but deep and compelling bits of story holding them together.
Reminds me of Evoland (although all of Evolands sections are at least partly RPG based rather than wildly different).
I think usually minigames are done using a scripting language.
I meant like, gameplay wise. User experience.
Music data can be read from the chip. When the music is interrupt driven a small buffer is needed that is filled from the main loop though as a SPI transfer shouldn’t be interupted by another SPI transfer
Flash chips used in SD cards usually suport a million rewrites vs 10000 and SD controllers also use wear leveling algorithms. So there’s a difference.
It is possible for a program to rewrite it self. The design should be so that rewrites are limited (finish one part, flash the next with a shared menu for example) Bad practise would be having a main menu and game as different programs that are alternately flashed when a game is loaded or restarted because the player died.
Someone could make an command interpreter and you can store all your (rewritable)scripts in the flash. ArduBasic comes to mind 
1 Like
I already have something a bit like that.
Originally it was supposed to be for storing the scripts in Arduboy’s progmem, but the flash expansion means the scripts can be stored in the off-board flash instead.
(It wasn’t a general purpose scripting tool though, it was for making a specific kind of game.)
1 Like
Seems you’ve been the busiest of all of us 
I’ve been distracted by other projects and need to jump back on this wagon. Is the new Tackle box structure much different from the current version? It maybe helpfull to know what to work on first.
1 Like
That’s a nice view 
kudos for the rainbow wire 
Looking good! So no hiccups this time?
1 Like
Shouldn’t be, the problem that I spent 2 weeks on last time just turned out to be the USB-C hub.
2 Likes