MegaBomber

Use this forum to share and discuss Uzebox games and demos.
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

Wot no Doom port?

The Uzebox is quite unique in not having a Doom port now. Some might see that as a feature?

Did you say you've done 16(sixteen, one six) tracks for this!?! That's another Uzebox record smashed if so right? I don't think I've seen a Uzebox game with more than 2 or 3 songs yet unless I'm missing something?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: MegaBomber

Post by Artcfox »

From your description, I think this is going to blow people's socks off! I can't wait.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Thanks for the support guys :)
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: MegaBomber

Post by uze6666 »

The Uzebox is quite unique in not having a Doom port now. Some might see that as a feature?
And what about running Crysis?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Struggling to coordinate this with a 32x32 Amiga ball right now.

Once that's achieved though, how hard could some polygons, a few pixel shaders, and a splash of anisoptropic filtering be 8-)
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

D3thAdd3r wrote: Thu Mar 09, 2023 5:49 pm Struggling to coordinate this with a 32x32 Amiga ball right now.

Once that's achieved though, how hard could some polygons, a few pixel shaders, and a splash of anisoptropic filtering be 8-)
Upcoming boingy joy!? The Commodore demo scene (AKA the demo scene) will be pleased!

https://www.youtube.com/watch?v=7TNkokz9BLU

(That track features the lyrics "I look at you and I go boing, boing, boing" :D )

The Uzebox should be a standard demo scene platform. Normalise the notion now!
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

DA hasn't posted the .uze files yet so I might as well do it, presuming its OK with Lee? Delete 'em otherwise.

They all run fine on my 'box except MB1 which is super crash happy.

Can't wait for the new, improved real deal edition!
MB0.uze
(53.89 KiB) Downloaded 64 times
MB1.uze
(54.38 KiB) Downloaded 62 times
MB2.uze
(54.63 KiB) Downloaded 60 times
User avatar
danboid
Posts: 1931
Joined: Sun Jun 14, 2020 12:14 am

Re: MegaBomber

Post by danboid »

MB3.uze
(54.81 KiB) Downloaded 58 times
MB-SandMan.uze
(52.1 KiB) Downloaded 70 times
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Perfect, thanks for making those.. The real deal gameplay-wise, will basically just be like MB-SandMan. Maybe the players will be able to throw bombs like the "ghost bombers" can. Originally that concept was scrapped to save flash on the extra graphics(you can walk with a bomb...so nearly doubles the sprite frames). Might flicker too bad not sure, but there will be extra flash for something due to offloaded menu graphics, music, SFX, and AI(Uzenet bot). Other than that just nice menus, finish details, etc.

Shifting thoughts on this as the music meets the SFX. It's difficult or at least annoying to design a game with random "check the SD, if we started a read before VSYNC last frame, see if it's ready" function calls everywhere; where is even a good place during gameplay, stackwise, in case that gets interrupted? Also robbing user cycles to increase PCM speed, so that user code can have more cycles...is silly when you *must* hit a sector read every < ~1.9 frames anyway. The game has to run smoothly at some point(meaning buffering ahead of demand actually) or it isn't realistic.

The main trick this started with is just using the wasted cycles a game normally throws at WaitVsync(1) to run an extra load. It's clear now that as much waits/work as possible needs to be pushed to HSYNC as well, so that by the time the bulk of the code gets to run again, any stalls were taken care of during scanline rendering where it doesn't matter. Right now I'm eating all stalls during the small amount of time I have just to get the overall juggling system implemented. I'm hopeful an order of magnitude improvement is possible just by pushing the spinlocks to where they don't matter.

Overall this is getting pretty complex and I'm glad I took the C approach to start, as most of it is just calculating when, where, and what to buffer. This way I can incrementally push portions to assembly and verify things still work. There really is no way to pull it off without assembly I now see. HSYNC code will check if there is an SD command in process. If there is, it will kick out an 0xFF per scanline, and if it gets back 0xFE, turn off the check. Better would be to have the full SD FSM inside HSYNC if possible, though this initial step should yield the bulk of the theoretical gains.

Basically I will start slicing out what I need from sdBase.s and see what happens. From the start I had assumed blocking functions would become the main issue, and here it is.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: MegaBomber

Post by D3thAdd3r »

Taking a break on this to let the subconcious do some refactoring. Small but positive inprovements have me believing this is possible more so than before, but my brain is tapped out for now. This is to be a complete game though, so there are lots of other parts to consider. Besides making good use of the SPI RAM, there is the ESP8266 to consider. Below are my plans for Uzenet in MB.

NAT is defeated by a game server which facilitates meetup/communication of players without the need for sharing network information, doing port forwarding, etc. The server is agnostic to the data in use, and that is a subject I'll expand on later as I have some code for it.

Once the meetup/chatroom utility sets up a game, it issues a bootloader request for the agreed upon game. In this case MB will attempt to send a server command asking for connected players. In this case since the ESP8266 was not reset, it gets the other players, their names, and the virtual player number(connected to P1 locally doesn't mean you are P1 in game). Then each side sends a command to switch to "sync mode". To escape it requires sending an "impossible pad state", where it's back in command mode. This lets a game query server data(like other players names), for menus, in game chat, etc.

No network prediction because there aren't resources for it. TCP instead of UDP because it allows significant simplification. Essentially something similar to ZSNES/SNES9X(and many others) general purpose networking strategy. Instead of reading the joypad and immediately processing the reaction, it is sent to the other side with a tick number. Several upsides, main downside is higher latency versus peer-peer.

The server collects inputs from all players, and once all are there, they are sent to all players as the input state for 1 game tick. This means the server doesn't care what frequency the game runs inputs at, it is controlled by how frequently the Uzebox game sends data. Each player is sent a copy of the padstate for all players(including their own sent earlier), and a game tick can proceed. With low enough jitter, this will turn into a stream of sequential simulations on all Uzebox clients. LFSR sync at start is facilitated by a server generated value to use on all clients. A small application specific state checksum(or just 0) data byte is sent with each padstate to detect desync.

To smooth out jitter so it's playable, a sliding buffer is used, as in all other real time services, running over best effort packet switched networks(ie VoIP, etc). I'm calling this "Lag Frames". That is some ancient remembrance of source code for some emulator probably 20 years ago, not sure. Anyways Lag Frames are the amount of frames to run ahead of the available input. Instead of constant jitters/stalls as data is delivered early then late, all clients run fame logic the same amount of frames ahead. The larger this value, the higher the delay in response, but also the lower the "yoyo effect" comes into play. A predictable delay is far more playable than a stuttering one. Since the server is controlled by the frequency of client updates, this would work for any implementation while allowing non-padstate systems to work also without special server side code(program says how big the data is, can be interpreted in any way). Basically allow the input to get ahead of the demand.

This is slightly more advanced than Doom(1993) networking done over serial/modem/IPX. It is still just a lockstep simulation, but it tolerates latency/jitter you wouldn't find in LAN or analog dedicated lines. This works decently for any game, and this is why emulators did it this way(not the incredible modern prediction/rollback stuff like in fighting games now). There is no system which can fix a very jittery connection and make it smooth. You can only fake it so far, here I'm saying make the latency transparent/raw without any expensive attempts at obfuscation.

Basically this allows a game to graft in networking just by changing their input routine. Always send local input for a tick immediately to the server. If the tick about to run, plus Lag Frames, doesn't have input from other players(server makes 1 batch of this, simplifying things), wait 1 frame and try again. When the server detects clients are resending the same logic tick input several times(stalling), the Lag Frames are increased until it doesn't happen. Most any game code will run without needing to be aware of this. There will be occasional artifacts on animation timing, but this is easy enough to make a real working game so it's a practical trade, IMO. Games could electively get more involved to handle delays better, but it's not simple.

That's my plan, and basically everything is aimed at simplification. I don't think port forwarding is convenient, nor NAT "hole punching" reliable. Just that justifies the server IMO, but it yields much more than getting things started. It also shields IP addresses from other clients, and can be used as a central arbitrator automatically where the game needn't know this is even happening.
Post Reply