General Coding of Continuum Questions

[»CypherJF]

My brother and I have been throwing out ideas on how we each think Continuum actually accomplishes a few tasks:

 

one of the things we aren't too clear on is how the 'large' maps are handled.

coding something like sniper (original ss) is simple enough, but for maps like 7 times larger (i know that's not the right dimensions) we figure he is using some kind of method to splitting the map up into several smaller sized "quadrants"

to cut down the amount of data it has to go through... any enlightment on how maps are handled in general?

 

We saw the discussion about the collision detection, and thought about ratio-ing a black and white image for the tile collision down to a 16:1 map... but somewhere we remember hearing priitk say that angled walls would be an ez code to impliment. but with 16:1 map you'd have to pixel perfect detect the large map for when it collides, because on a small map the angles wouldn't exist in a 1x1 pixel...

any suggestions other than making a large 1:1 black and white tile collision surface?

 

any !@#$%^&*istance is greatly appreciated.. sorry i/we sound like newbs we're just trying to reverse engineer a game into something similar to SS/Continuum... Thanx - cypher/splat

[mister manners]

not very noobish sounding like to me... r you trying to code a simple continuum, or reverse engineer a game that allready exists thats like continuum?

[Trained]

I think he might just be trying to understand the basic coding of the game, like me.

[Snrrrub]

I'm not sure what you're trying to say with your "ratio-ing" of black and white images onto 16:1 maps. And the other question is pretty ambiguous too. What do you mean "how are maps handled"? Are you looking for the data structure used? Or do you want to know what information is stored "in the map"? What I can tell you is that the tile map is neither logically nor physically sub-divided into sub-regions on the client while performing collision detection. Hope that helps.

 

-Snrrrub

[»CypherJF]

not very noobish sounding like to me... r you trying to code a simple continuum, or reverse engineer a game that allready exists thats like continuum?

I'll try and answer these to the best of my ability w/o splat being here...

 

Well sortive, we're trying to figure out how Continuum actually works, so we could apply the same ideas towards a continuum-like game. Make better sense?

[»CypherJF]

I'm not sure what you're trying to say with your "ratio-ing" of black and white images onto 16:1 maps. And the other question is pretty ambiguous too. What do you mean "how are maps handled"? Are you looking for the data structure used? Or do you want to know what information is stored "in the map"? What I can tell you is that the tile map is neither logically nor physically sub-divided into sub-regions on the client while performing collision detection. Hope that helps.

 

-Snrrrub

Once again, i'll explain my best w/o splat being here.. But...

 

What I can tell you is that the tile map is neither logically nor physically sub-divided into sub-regions on the client while performing collision detection.

I think that's part of the solution we were looking for..

 

I guess here's our deal. We were looking at having 1 huge surface (whatever 1024*16x1024*16); and move it around, using the 16:1 ratio map to determine if we need to check for collisions (essentially)..

 

But moving that big of a surface seemed tasking on some machines :/ so maybe our question should now be, does continuum handle it differently where the big surface is actually like split up into smaller surfaces? or are we off the wall?

 

Thanks for you're guy's help; sorry for the unclear post..

 

- cyp

[»nintendo64]

I did a search on my hard drive about the drawing of tiles, and i found a discussion between JeffP (The Creator or SubSpace) and Mr Ekted (GUI Maker of Continuum, PowerBot, etc..).

 

Mr Ekted>

 

JeffP:

Priit's initial goal is to replicate SS as close as possible so that the current player base is not alienated. I am implementing the front end based on his requests. All of my work is original, based on observation only of the old SS client (any images in the screen shots that I don't have the rights to distribute will not be included in my code).

 

As far as optimization goes, there is one big this that can be done to improve frame rate, which I am guessing you missed. In all arenas where there are alot of tiles, frame rate drops. My guess is you draw each tile as a separate 16x16 pixel Blit(). If long horizontal or vertical runs of the same tile can be detected at map load time, they could be Blit()'ed in 1 larger block. I know on my video card (nVidia TNT1 16MB) this could have the effect of no noticeable loss of frame rate in "busy" areas.

 

If I had my way, the advanced options dialog would be gone. The few things in there that are useful (avoid flip, etc) could be moved into options and enclosed in an "advanced" box.

 

It's nice to have you participating in some of these discussions Jeff. I hope you find [at least] our intent flattering and not offensive. I will go out of my way not to step on anyone's toes, but the bottom line is that my efforts are for the good of the player base, whether it be a new "Subspace", or a new game from scratch. Unless BDE gets you to work for them, I think "we" have a much better chance of keeping the player base, then they do of taking over.

 

JeffP>

 

I tend to agree Ekted. Levels were never really intended to have large blocks of tiles (you will notice VIE maps never did)...However, I have noticed this has become popular in user-made maps. I do blit all the tiles one at a time and it is fairly costly (setting up the blit costs more than the blit itself with tiny blits like that). I did consider pre-rendering strips of tiles as you suggested, but decided against it for a couple reasons:

1) The current tileset generally manages to fit in video ram, though at the time there was rarely any room left over in vram for other surfaces (as was, at high resolutions some of the base graphics didn't even make it into vram on 4mb cards, which were high-end at the time, it seems silly now, but even things like roll-graphics were considered optional effects that many people might not be able to load).

 

It is also worth noting that the machines that have more vram than that to spare also tend to be the machines that weren't having performance problems anyhow. This effectively meant that pre-renderings would end up in system ram. I figured the cost of blitting them across the PCI bus (remember this is before AGP existed) would be more expensive than setting up the individual blits. System memory wasn't exactly in abundance either.

 

2) Each strip of unique tile combinations on the map would have to be pre-rendered independently. I figured the number of permutations would far exceed available memory in no time (vram or system-ram). Particularly given that the dense tile sequences were often non-repe!@#$%^&*ive, that is, players often did things like make pictures or spell things with their tiles, which effectively results in non-repe!@#$%^&*ive patterns and even more memory usage.

 

I also considered an option whereby strips that were on-screen would be pre-rendered on the fly as they came on screen. The end result of this is that as they first appeared they would be slower than normal as they would have to double blit, but once on-screen they would become faster than normal. Again, a lot of the same issues came up, particularly the lack of vram issue. I opted against doing that as the end result would be slower frame rates potentially while scrolling and faster frame rates while holding relatively still (you see the catch 22 in this I assume).

 

I suspect given that a lot of cards now days have 32mb of VRAM, that the pre-rendered strips technique will take on increased viability. However, it's worth noting again that machines with those types of cards aren't having the performance problems anyhow.

 

The Infantry engine makes heavy use of the concept of pre-rendering to get the performance it does. I run zones like gravball which are fully populated with graphics at 1800x1440 at 50+ fps on my G400max...and that's at a 16 bit color depth with alpha-blending occurring, so it's certainly worth a look-see.

 

As per my feelings on this endeavor, I don't take any offense to your efforts at all (I only mentioned the advanced options dialog box because I couldn't figure out why anybody would want to simulate that). I won't be working for BDE anytime soon either(I have my hands full at Sony). Also, I have other types of games I would like to move onto, subspace is certainly a happy chapter in my career, I loved making it.

 

I hope this thing doesn't turn into a compe!@#$%^&*ion between you and BDE as things might get a bit distasteful if it does. Quite frankly, I am bit surprised BDE is trying to revive the game. They are a for-profit outfit and they wouldn't do it if they didn't think there was money in it somehow. I don't see how that can happen given what the fan base expects and what the game has to offer compared to more modern games. While you and I will forgive subspace for it's atari-like graphics because the gameplay is so compelling, most people won't now days (even back then a lot of people wouldn't).

 

I am not sure what brought me by this message board (somebody icq'ed it to me I think), but I doubt I will be stopping by much (though maybe I will take a fancy to it, who knows). Anyways, best of luck, I am rooting for you (though I think powerball players really should give GravBall a try, it is everything powerball is and so much more)

 

Something JeffP said about Diagonals

 

Many of the comments have been right on the mark. Diagonals would be fairly easy to add to the existing scheme and pose no performance implications -- Infantry does diagonals in this manner (though the isometric view complicates things a little bit more). With modern computers I wouldn't worry too much about doing any odd angle, remember when Subspace was designed, I had a Pentium 60 and thought I was cool...many of our player base had 486's and trig was expensive, particularly when you start tracking literally hundreds of objects (animating internally on a 1/100th of a second clock tick).

The hard part about doing odd angles is describing it. The simple tile-based scheme would pretty much have to go and be replaced with an object to object physics scheme. To do this you would need to be able to very quickly access objects that might be of interest to the object you are managing. Typically hash tables are used for this purpose. My really old game (CyberBykes) used a technique like this.

 

The rendering engine would need massive changes as would the physics code for various types of objects. I guess what I am saying is that the current crop of computers would have no problems if it were well implemented, but to do it right is not a trivial change. Adding diagonals would be a fairly trivial change. Then again, since you are rewriting it all anyhow, doing it in a manner that supports more features should be almost as easy as the other way.

 

With Infantry, I changed the graphics to a free-form model instead of being tile based, but left the physics as a tile-based overlay for performance purposes. If I were doing it over again, I would tie the physics to the free-form objects entirely and use a hash scheme as I did in my cyberbykes game to quickly identify the set of objects that I need to do more detailed collision checks on. Since most of the map is empty space for Subspace, if you did this, I would recommend a bit-mask of the tiles indicating which areas of the map possible had physics collisions, then you would only need to go out to the object table periodically to test for actual collisions. You could then effectively get any angle and even curved surfaces if you were diligent. Not trivial and not backwards compatible (though a translation utility could be easily written).

 

But, if you start doing stuff like this, you have to ask yourself why you're not just writing everything from scratch...there is a lot of stuff that can be done better...but there is always the risk that you will ruin whatever it is that makes subspace popular to the current player-base...

 

 

 

-nintendo64

[madhaha]

I wish someone tried doing it from scratch anyway...

[Snrrrub]

Ah, that makes more sense. No, it's not one giant surface -- that would be insane. You basically have your drawing surface which is the current resolution (say 1024x768). Every frame, you clear the surface and draw tiles onto the surface. So every frame, you look at where you are and what the resolution is. Based on that, you can find out which tiles you need to draw by looking it up in the map.

 

-Snrrrub

[»CypherJF]

Thanks nintendo and snrrrub XD