Multiplayer FPS
Moderator: MaxCoderz Staff
For the z80...I doubt it. The 68k calcs are fast enough to handle it though if played around with right. Texas Hold-em would be a good place to start with a big circle of calcs...
Visit Nerdy Productions
Yeah, there's an 83+ bomberman one(very awesome), alien breed one, falldown, chopper, etc etc. There's a bunch.coelurus wrote:Are there any realtime games with linkplay? I've never touched the link port and I probably won't delve deeply into it, but it'd be nice to see working routines and to expand on them. The TI83 SDK has some info, but nothing proven for realtime apps.
bananas... o.o
Here's a really bad ASCII diagram:
if the chain ends in a Titanium, that calcs can form a loop with an I/O link, otherwise it would be a chain. Also, you can start with an I/O link.
Code: Select all
USB I/O USB
89Ti-------89Ti-------89Ti-------(and so on)
Visit Nerdy Productions
-
- Calc King
- Posts: 2195
- Joined: Sun 27 Mar, 2005 4:06 am
- Location: sleeping
- Contact:
What's up with all these 89s, don't they already have mp FPSs? The tricky bit is to get the sluggish 83s (84s?) to do linkplay so let's concentrate on that
What's the general problem when it comes to multiplayer games? Register the number of players, await ready-signal, start main loop, wait until keypress info has been distributed through the network and let each calc compute what happens. Letting calcs compute everything individually will easen up on the link and as long as no texturing is used, there should be no problem computing everything in the "arena". If the link can xmit more data per frame than keypresses, then maybe computing could be distributed over all clients. It's a choice determined by experimentation; if the link is slow, send keypresses and compute everything per client, else split computations and send world data.
What's the general problem when it comes to multiplayer games? Register the number of players, await ready-signal, start main loop, wait until keypress info has been distributed through the network and let each calc compute what happens. Letting calcs compute everything individually will easen up on the link and as long as no texturing is used, there should be no problem computing everything in the "arena". If the link can xmit more data per frame than keypresses, then maybe computing could be distributed over all clients. It's a choice determined by experimentation; if the link is slow, send keypresses and compute everything per client, else split computations and send world data.
- Loki
- Extreme Poster
- Posts: 314
- Joined: Thu 18 Aug, 2005 7:01 pm
- Location: My world is in grayscale, but if i stand still long enough, i see it in black and white.
- Contact:
Speaking of FPSs, you've probably seen that Heretic idea..i'd really love to see that happen..Just think, destroying D'Sparil and his minions in Geometry or other boring class. What would be better? Well, for one, if this mp FPS is a success, destroying your friend with a phoenix rod...or pwning his ass with an elven wand xD
Well, how I do it on the PC is I save an array to use as the heightmap and then use a formula to correctly calculate the height of the player at any given point on the map. To draw a 3D model of the terrain, I use the heightmap and draw a primitive triangle strip, and save it as a model for speed(meaning I don't have to recalculate each triangle every draw event). Somehow, though, I don't think it will be so easy on a calculator... Which reminds me...sometime this year I should update my website.coelurus wrote:Btw, what's up with that 3D terrain?
bananas... o.o
3D terrain on a calc? Sounds like fun, although not practical. Terrains are large and enemies can be far away which means they'll become pixel blobs. Go for indoors, either raycasting or very simplistic portal-friendly environments. There must be zero overdraw and no filled faces, which means we get back to the old how-to-cleverly-clip-wireframe-worlds-problem.
I got two solutions:
A fellar from Denmark whose name I've misplaced gave me this Anyway, his idea consisted simply of a vertical buffer holding left and right boundaries for portals between convex sectors that gets backuped and updated for every new portal. Personally, I'd prefer to do it "the portal way", which means using quad portals only and generate frusta for every new portal, because this will speed up clipping a lot and there will be no need to copy boundary-buffers. Furthermore, calculating the size of a portal will be lots easier (useful to skip out from the recursion of portals). Since there will only be quad portals, updated frusta will always have quad shapes. Moving objects will work flawlessly with this.
Another solution is to use an image-space structure, like an S-buffer, to insert the few couple of spans per row needed for one view. Clipping spans will not be necessary and since the portal-scheme will 'sort' the scene front-to-back, the largest spans will start out and smaller spans behind will be discarded early. A little tricky when it comes to moving objects, inserting them into the S-buffer is the most robust way, but it's gonna devour a lot of spans.
Beam trees? Not sure about that, would be fun to see how that performs though.
My thoughts on a truly 3D world, but raycasting seems more viable still.
EDIT: Why do a large number of my posts end threads? It's almost as if I kill the interest of some topics This usually happens when I go ranting about various ways to solve things, I thought answers lead to action
I got two solutions:
A fellar from Denmark whose name I've misplaced gave me this Anyway, his idea consisted simply of a vertical buffer holding left and right boundaries for portals between convex sectors that gets backuped and updated for every new portal. Personally, I'd prefer to do it "the portal way", which means using quad portals only and generate frusta for every new portal, because this will speed up clipping a lot and there will be no need to copy boundary-buffers. Furthermore, calculating the size of a portal will be lots easier (useful to skip out from the recursion of portals). Since there will only be quad portals, updated frusta will always have quad shapes. Moving objects will work flawlessly with this.
Another solution is to use an image-space structure, like an S-buffer, to insert the few couple of spans per row needed for one view. Clipping spans will not be necessary and since the portal-scheme will 'sort' the scene front-to-back, the largest spans will start out and smaller spans behind will be discarded early. A little tricky when it comes to moving objects, inserting them into the S-buffer is the most robust way, but it's gonna devour a lot of spans.
Beam trees? Not sure about that, would be fun to see how that performs though.
My thoughts on a truly 3D world, but raycasting seems more viable still.
EDIT: Why do a large number of my posts end threads? It's almost as if I kill the interest of some topics This usually happens when I go ranting about various ways to solve things, I thought answers lead to action
http://education.ti.com/us/product/tech ... tures.html
I know I can go off-topic at times, but your post must break all records
I know I can go off-topic at times, but your post must break all records
-
- Sir Posts-A-Lot
- Posts: 252
- Joined: Tue 09 Aug, 2005 9:34 pm
- Location: south of the north pole
- Contact:
Bomberman is the only one that is really good. Alien Breed doesn't link right, falldown and chopper have bugs and are only on one screen, and i haven't heard of any other linking games for 83+.Spengo wrote:Yeah, there's an 83+ bomberman one(very awesome), alien breed one, falldown, chopper, etc etc. There's a bunch.coelurus wrote:Are there any realtime games with linkplay? I've never touched the link port and I probably won't delve deeply into it, but it'd be nice to see working routines and to expand on them. The TI83 SDK has some info, but nothing proven for realtime apps.
-
- Calc Wizard
- Posts: 526
- Joined: Tue 08 Mar, 2005 1:37 am
- Location: who wants to know?
- Contact: