Perfect, considering resolution, ram limits, and not having any credit card information on the Uzebox: the name and password lengths should work nicely(I wouldn't even bit pack them down for A-Z,0-9 to keep things easy).uze6666 wrote:What about reusing the MAC and reserved bytes:
My initial assumptions about Uzenet are radically towards simplicity and standardization. People should just buy the Uzenet module and an ESP8266 pre-programmed with it perhaps? It depends how much burden that puts on you, maybe it's no good. Otherwise I thought it would be nice because it is a pain to make a setup rig for firmware updating as it's not breadboard friendly spacing, but really, not too annoying...and who am I kidding, that would be the absolute last thing I'd want to work on since it's not that fun.uze6666 wrote:Also esptool is nice, I see it often in other forums. Regarding custom firmware, I recently saw there's an aduino IDE fork released to build and deploy custom firmware to the ESP8266!
I saw that Arduino setup and it looked promising but I haven't tried to build anything yet. Part of it is I'm not sure I understand it either; it looks like they just give you some basic functions you can use and hide the rest? The espressif firmware is much lower level and has access to every detail. You can see the crap that is adding the network delays we were talking about, and I'm sure you could see why there has to be a UART delay between commands if dug into more. If there is access to low level UART and network details then I'm all about it. I'm still not at the point where I am working at all on this aspect. BTW on the kernel side stuff, one of your uzenet demos really had the basic stuff that should be official already working. Past that I think a state machine is a necessity which can't be generalized well, I assume?
Oh yes definitely would be cool. if you look at http://uzebox.net you can see a pretty humble web page mock up. Now the low level stuff could be handled/stored by the server, and later if we want to mix in websockets to access the data or whatever, there could be fancier stuff. The server keeps track of what time it is right now but does nothing with it. When it's up and working we could just have time stamps for each score, and occasionally run through all the data and output some different tables to update the index.html file on the disk. A simple webpage with generated content shouldn't be too much of a kludge even in C for an interim solution.kivan117 wrote:Would All Time and Weekly lists be possible?
So my thought, say you have something like this pseudocode:kivan117 wrote:For racing games like this where fastest time is per track how would we keep the scores updated? Also, time is a slightly trickier thing to track with a single "highest is best" number.
Code: Select all
uint32_t total_race_ticks;//less is better
//rest of your game stuff
#define MAX_VAL 4294967295UL
//somewhere else...
while(1){
WaitVsync(1);
//do racing stuff
total_race_ticks++;
if(race_is_over){//send our score to uzebox.net!
//connect, fight annoying text and delays, send normal packet stuff, and all that...
uint32_t mag_flip = (uint32_t)(MAX_VAL-total_race_ticks);//subtract max 32bit value from our total race time
SendUzenet32(mag_flip);//we send a higher score for a faster total race time, more is better
}
}