real Jaguar polygons/s count & voxels

[Symmetry of TNG]

Hi!

 

Sorry for making a new "thread" with the same subject as an old one. BUT if not I fear that it will not be read. And since this is my first post on this forum I whant atleast someone to read it, espessially Gunstar then so he gets what he wants =)

 

And may i please ask that this thread is not turned into some maindless yelling (please!).

 

 

OK here I go. This weekend I thought to make some "benchmark" of the jaguars polygon count... So I took a pen & counted the polys when playing IS2 ... =0) ...ok JOKING!!! =)

Not realy but here is ...the somewhat "sad" truth about the polycount:

 

Test conditions:

Only GPU&blitter doing the poly. The 68K is actually polling a vbl variable to check for vbl (stupid I know but Im lazy! =) this might slow down the bus to the relatively "low" values below.

One 320*200 framebuffer.

 

The verdict is as follows:

Fully Gouroud shaded object, (slow!) software clipping is ON:

1st # represent poly size, "pure triangle" lower right corner. (ie upper corner is half that value but at y=0) ...ahh it doesnt matter its a triangle! =)

Same poly is blitted over & over and here is the count:

 

 

(16,0) (0,32) (32,32) (1st one for clarity this is poly screen coords)

polycount=4426 p/s

(64,64) polc=2087 p/s

(128,128) polyc=1011 p/s

(16,16) (just for test) polyc=8021 p/s

 

 

Texture Mapped polygon:

Clipped, arbitrary sized, flatshaded:

(32,32) = 2699 p/s

(64,64) = 845 p/s

(128,128) = 233 p/s

(16,16) = 6717 p/s

 

 

Thats it! =) ..havent tried flatshaded but it is shurely much faster!

(much less setup)

.

These values is what could be expected in a 1st trye of a "homebrew" optimized for 3 edges, polygon routine.

Unoptimized code (meaning waitstates could be removed or sincerely reduced! -> setup code will run up to 3 times faster! increasing polygon count) But the limiting factor is the blitter.

 

Just as an example i tried to remove the clipping (that is allways done now... yeahh.. i know stupid but still =) ..and the poly count went up by a 1000'nd ie 5414 p/s on the small ones.

 

But what one should do is to true to use the phrase mode as much as possible. this can be done in flat & mostly for gouroud shaded polys but not for texturemapped polys where the blitter has to be in pixelmode all the time, SINCERELY reducing the speed of the polyrout, especially for large ones.

 

In pixelmode the speed is dependent on the area of the poly, but in phrase mode it is only dependent on the height of the poly. Ie in phrase mode: the wider polys you blitt the more "efficient" your blitt is... (?) =)

 

In "perfect" gouroud shading there is sometimes a "phrase miss" that forces you to blitt a scanline in pixelmode reducing the speed of the blitt. Perhapps accepting flicker for speed could be an ide?.

 

 

Thats all...most all.. remember under which the circumstances the test was made. Ie unoptimized, only gpu&blitter... so see it as "worst worst case" =)

Also that this is the polys that get shown on screen and not the maximum polys / object which is something totaly different! (note menny of the polys in a object get "culled" ie is facing away and hence should not get drawn)

 

 

Last thing:

About Phase Zero... I remember asking before if anyone that can play it can approximate fps count for me? I would just like to know... and the effective screen size.

The thing about "voxels" in PZ case is that the landscape has to be blitted in vertical stripes... which means that the blitter has to be in pixelmode (darnit!) and not in the infinitely faster phrase mode. sincerely affecting speed.

(it might work in phrase mode but that would lead to more blockiness (4pixels have same hight) and less shading (only 32 levels) And i dont think PZ has that.... (or?)

 

 

Just a last note. the "voxels" in PZ isnt actually voxels... (you probably allready know =) ..but gives a similar effect... perhapps a 2D voxelmap that gets "stretched" to 3D =) ahh well...

 

 

Hope I didnt forget anything that I wanted to say =)

 

Thanx for reading (if you got this far ;o)

 

/Symmetry

[Gunstar]

Thay's alright with the new thread, the old one was getting long anyhow, regardless of the argument.

 

Thankyou very much for your numbers. It's actaully a much more detailed answer than I expected, at least in one post. I at least have some idea know of what is possible with what will be my unoptimized beginner's coding when I get started on actual coding in about a year. Right now I'm just doing preliminary game design (a concept and sketches of models and some minor preliminary level design). I'm an artist, so a lot of my objects and models will be made up for the game before even a line of code is done.

 

That is very intersting that the "voxels" in PZ are not "true" voxels, I didn't know that. I wonder if the same is true with Delta Force games? The landscapes look very similiar in both games. My GUESS on fps for PZ is about 15-20fps, just by juding the smoothness and quickness of everything. It looks quite good and fast.

 

Thanks again.

[Atari_Owl]

This is brilliant symmetry, thank you VERY much for the info.

 

About Phase Zero... I remember asking before if anyone that can play it can approximate fps count for me? I would just like to know... and the effective screen size.

 

For interest i actually videotaped a session while i played Phase Zero.

 

When i replayed and paused the tape, i saw a different image with every frame update, even when rotating the craft (i.e. not just updating the sprites but also the voxel background).

 

I would therefore suggest that the frame rate is around 20-30fps.

 

Once again Symmetry, many MANY thanks for the input.

 

Cheers

[Symmetry of TNG]

>1st a bit specific 4 Gunstar

 

Yes.. I have a tendency to write TO MUCH when it comes to atari =) (bad habbit)

 

Even "only a game idea" is good as long as it is "unique" ie if you whant to play it you have to buy a jaguar =) If the game is good enough it might lead to good publicity... (why one now would whant that =)

 

So your an artist. Just a small tipp if you make 2D bitmaps for the jag. keep the artwork the correct "blitter width" or if it is to be a OP object, keep it.. "OP friendly" ..(humm.. admits I dont remember but is that "even phrases"? =) All blitter widthes can be found in the "jaguar.inc" file in the coding utils. This is so you dont have to sitt and rescale all of your artwork when you (in the future) realize what it actually was supposed to be.

 

I personally beleive that if you whant to make a "good" game for any system you have to design the artwork for the hardware and not the reverse. Most artist dont like that... but since you planned to be a programmer its ok =)

 

 

Just a thought about TextureMapping:

There might be a way to use the blitter in a "semi-phrase" mode and get much faster texturemapping especially for big polugons. But finding time to code is harder than finding coding ideas! (

But I'll keep you posted...

 

 

 

 

Landscape Voxels:

Heavens No! true "volumnous pixels" (hur stavas det? =) is something for supercomputers! not realtime gaming. Since the amout of polygons grow ~ N^3. I guess you could see the voxellandscape as 2D voxels (but with a height value) Project two heightvalues lying on the same "ray" and instead of just plotting the "pixel cubes" you draw a gouroud shaded vertical line between them. "filling out" the space between, making it look solid. (Anyhow, why would you whant do draw all "dirt" under the landscape that you still dont see? like true voxels would do)

Im pritty shure any game that has "voxel landscapes" uses this technique. Even ones with apparent "texturemapping" If you exchange the 2D "colormap" with a texturemap, and interpolate between different colors, your landscape will look like texturemapped!

 

 

 

>4 Atari Owl

 

PZ framerate:

Humm... interesting... if you lived in europe that would mean that it is 25fps (i think, unless PAL video technology cheated me =) And that is impressive!

 

What about screen resolution ????

 

And grading in shading? ...ie stand infront of a big mountain (bottom -> top of screen) and at top has a bright color and at the bottom has a dark one (or reversed), does the shading of one vertical line look like 256 steps or 32 ?

 

I hope to see this game myself one day (under the "coding microscope" as usual but that is quite far into the future... (flash cart man! ...or alphine.. but neither is accessible)

 

 

Thanx for any replyes!

/Sym

[walter_J64bit]

woow! The J64 has been benchmark! Ive thought it would help.

[Tyrant]

Hi Symmetry, can you tell us a little about yourself? who you are, how you know so much Jag programing and when you'll be releasing your next game? (hehe).

 

Seriously tho, nice to find yet another expierenced friendly coder popping up out of the woodwork, one day I'll get the time to learn myself, but I use high level languages so much its very hard to drop down to assembly.

[Thunderbird]

Hi!

Just as an example i tried to remove the clipping (that is allways done now... yeahh.. i know stupid but still =) ..and the poly count went up by a 1000'nd ie 5414 p/s on the small ones.

 

But what one should do is to true to use the phrase mode as much as possible. this can be done in flat & mostly for gouroud shaded polys but not for texturemapped polys where the blitter has to be in pixelmode all the time, SINCERELY reducing the speed of the polyrout, especially for large ones.

/Symmetry

 

 

That's pretty detailed information, but I hope people out there will take into consideration that this is your first Jag polygon engine. The results you have obtained are not optimized in any way. There's a couple of things you can do to speed things up.

 

1) Improve your clipping code. It seems to really burden the system. It should be a lot less time.

 

2) Use phrase mode wherever possible. This is a no brainer. You even mentioned this.

 

3) Try to keep textures on the same page as the framebuffer. Blitting across RAM pages causes page faults which put a huge hit on the bus speed.

 

4) Get rid of the 68000 polling code. You're hitting the bus in a loop with the 68000. That is definitely a no-no.

 

That's all I can think of right now. More to come as I think of things.

[Gunstar]

>1st a bit specific 4 Gunstar

 

Yes.. I have a tendency to write TO MUCH when it comes to atari =) (bad habbit)

 

Even "only a game idea" is good as long as it is "unique" ie if you whant to play it you have to buy a jaguar =) If the game is good enough it might lead to good publicity... (why one now would whant that =)

 

So your an artist. Just a small tipp if you make 2D bitmaps for the jag. keep the artwork the correct "blitter width" or if it is to be a OP object, keep it.. "OP friendly" ..(humm.. admits I dont remember but is that "even phrases"? =) All blitter widthes can be found in the "jaguar.inc" file in the coding utils. This is so you dont have to sitt and rescale all of your artwork when you (in the future) realize what it actually was supposed to be.

 

I personally beleive that if you whant to make a "good" game for any system you have to design the artwork for the hardware and not the reverse. Most artist dont like that... but since you planned to be a programmer its ok =)

 

 

Just a thought about TextureMapping:

There might be a way to use the blitter in a "semi-phrase" mode and get much faster texturemapping especially for big polugons. But finding time to code is harder than finding coding ideas! (

But I'll keep you posted...

 

 

 

 

Landscape Voxels:

Heavens No! true "volumnous pixels" (hur stavas det? =) is something for supercomputers! not realtime gaming. Since the amout of polygons grow ~ N^3. I guess you could see the voxellandscape as 2D voxels (but with a height value) Project two heightvalues lying on the same "ray" and instead of just plotting the "pixel cubes" you draw a gouroud shaded vertical line between them. "filling out" the space between, making it look solid. (Anyhow, why would you whant do draw all "dirt" under the landscape that you still dont see? like true voxels would do)

Im pritty shure any game that has "voxel landscapes" uses this technique. Even ones with apparent "texturemapping" If you exchange the 2D "colormap" with a texturemap, and interpolate between different colors, your landscape will look like texturemapped!

 

 

 

>4 Atari Owl

 

PZ framerate:

Humm... interesting... if you lived in europe that would mean that it is 25fps (i think, unless PAL video technology cheated me =) And that is impressive!

 

What about screen resolution ????

 

And grading in shading? ...ie stand infront of a big mountain (bottom -> top of screen) and at top has a bright color and at the bottom has a dark one (or reversed), does the shading of one vertical line look like 256 steps or 32 ?

 

I hope to see this game myself one day (under the "coding microscope" as usual but that is quite far into the future... (flash cart man! ...or alphine.. but neither is accessible)

 

 

Thanx for any replyes!

/Sym

 

Thanks for the Jaguar art tips. Right now I'm only doing pencil and charcoal sketches of some ideas for things I have that go along with the idea I have for my first game, so it'll be all redone many times over before they get to the point of Jaguar graphics. But I don't even know how to program (assembly or C) right now, and won't be scheduled to take the classes until next fall or maybe summer.

Right now I'm taking courses on the hardware end of my Electronics degree, and circuit&gate logic, etc. The closest I'm getting to coding right now is a computer networking&OS systems. we'll scratch the surface on some coding, but it's mostly just command line syntax and working with the physical hardware. I'm not going into programming itself as a degree, but I will have to learn some stuff, especially assembly, so I figured I might try my hand at coding the ST and Jaguar for a hobby, since I'll be learning a common language anyway.

[Symmetry of TNG]

Who Am I ? ...(thats a Jackie Chan movie btw =0)

Lets just say I have ca 10 years of assembler experience and that I have been here forever... waiting for serious diskussions ;o)

 

Programm atari for fun. Finaly found my system when I started jaguar some 2 years ago, on and off, as a hobby. And that is what it will remain... if it leads to a game Im happy if it dont, Im still happy because nothing beats coding assembler =) (this is my replye to Tyrant ;o) Once you go Assembler u never go back =)

 

 

2 Thunderbird:

 

Thanxfor the tipps. Some thoughts about them:

 

1) God I wish A1_Clip could work! but i tried that and when a gouroud line starts before left border the hole line turns black ! (?) like biinc isnt added to p_data ? When poly goes out on the right there seem to be a flicker consistent with Bug# ..? god knows, but it clippes some phrases to soon... Anyhow thats why I aimed for software clipping. And heres the story about that:

 

The rout is a "optimized" 3Edge rout, opti in the senze that when you have 3 points they always lie in a plane and parameters is constant over the surface. Now clipping... Humm.. i thought that i could use the "parrallellism" of the jaguar and that would not hurt the system that much. Ie while the blitter is blitting the previous scanline the gpu process&clips the next one. In theory it sounded nice =) Guess i have to reconsider (but 1st I'll kill waitstates). Because i still beleive that it should work. With all that "dead setuptime" the blitter has + blitting time, should be enough time for the gpu 2 clipp 3 values!!

2nd thing is that clipping that poly theoretically correct (SH algo, or whatever) on the left edge isnt that trivial (or is my brain dead?) Since a 3edge can become 5edge (more?) and i dont whant to start coding a N-edge case :/ Any ideas?

 

 

2) In gouroud it uses phraes as often as possible! I think. except when line is shorter than 31 pixels then switching to pixelmode makes the blitt faster due to less setuptime.

Also when colorgradient is to big for phrasemode, pixelmode is used. Hopefullt that doesnt hapen that often. Depends if the polys start on a dark color or not. And that should only happen on the edges (if light sorce is head on =)

 

 

4) Hmm.. yes.. So i have heard (Hi cts ;o) I know i should stop it, but how? ..in the st one could write "Stop 2700" or "2300" and it stopped dead in the water. but what to write on the jaguar? Is it the same? (remember trying it and the instructions after defenitely got executed).

 

3)

Yes I thought about this... but it just messes upp my brain when i think about it =) if i have to interleave first 2 framebuffers and then t-map data allso ...Arrgghh!

This brings me to texture "cache".

I tried having the tmap in dspram thought it would speed thing up having the bitmap in sram, but what happened? ...speedwise ...well slight increase but not 50% as hoped (like 10% perhapps) BUT worst was that the data got corrupted!!

Seems like INC mode doesnt work properly from dsp memory, why? (is it because 16bit bus to dsp?, but it shouldnt matter since INC mode fetches 1pixel at a time). Dissapointed was I :o/

 

Next question: if blitter is using dram the gpu can work in parallell in its sram right?! ..Now assume that there is enough space in gpuram to store a texturemap (the chalange to code on the jaguar optimize both for space and speed! =) Now if the blitter is blitting texturedata from sram -> dram will the gpu be able to execute code in parallell? ...(i dont think so, since it isnt "dualport sram" or something). And will blitter acessspeed to sram memory be 25MHz and to dram slower? (meaning atleast one fetch is fast while the write is slow).

(But if this inhibits the gpu to run in parallell with the blitt, it is not the way to go).

 

Still beleive that my "semi-phrase" texturemapper ide could work.. =) just that it requieres that i rewrite everything! ( (will not tell more untill I test it, If it works like i think it will I'll get it copyrighted ;o)

 

(This feels a bit lite "reinventing the weel" here, I "waste" 1/2 months on coding just to see that it isnt fast enough, comes upp with a better idea and back to scratch... Yes yes I know.. I said i am coding for the fun of it, so Im not complaining! =)

 

 

Thast it. (once again sorry for the kb's of ascii }

 

regards

/Sym

[Atari_Owl]

What about screen resolution ????  

 

And grading in shading? ...ie stand infront of a big mountain (bottom -> top of screen) and at top has a bright color and at the bottom has a dark one (or reversed), does the shading of one vertical line look like 256 steps or 32 ?  

 

I'll have a look tonight, it looks like its a pretty standard 320x240, i.e. not so grainy as Doom.

 

I'll also look at the shading, it looks extremely smooth but i'll have a check just to be sure.

 

I do have to say it looks and plays phenomenally well. What a terrible shame it was never finished.

 

Cheers

[Symmetry of TNG]

Just a note... my ascii smileys does NOT lite this forum, they turn into something completely different.

I know, I know, im a beginner to this "high tech" forum (equals to, right paranthesis).

 

No Its Lunch time, Im outahere!

 

/Sym

[Stone]

I guess you could see the voxellandscape as 2D voxels (but with a height value) Project two heightvalues lying on the same "ray" and instead of just plotting the "pixel cubes" you draw a gouroud shaded vertical line between them. "filling out" the space between, making it look solid. (Anyhow, why would you whant do draw all "dirt" under the landscape that you still dont see? like true voxels would do)  

Im pritty shure any game that has "voxel landscapes" uses this technique. Even ones with apparent "texturemapping" If you exchange the 2D "colormap" with a texturemap, and interpolate between different colors, your landscape will look like texturemapped!

 

I thought the way to do it would be to have a 2D height map (like DOOM, btw), placing a voxel at each point, at height set for that location. With a high enough resolution this would appear as a 'sheet' that is 'folded' into the contours specified. There is no 'dirt' under the landscape, as the landscape is just a surface. You have problems if you fall off the edge of the sheet though (this can happen in Quake)

 

You also have problems if your clipping code is buggy; say you drive a vehicle over the top of a big hill, then fall through the air and hit the dirt on the other side. If part of the player goes *through* the voxel-based surface, then they'll either get stuck or be able to view the underside of the sheet, which would be bad

 

Maybe that's what you said, my 3D knowledge is still at vector transformations so I'll shut up now

 

Stone

[Tyrant]

Just a note... my ascii smileys does NOT lite this forum, they turn into something completely different.

I know, I know, im a beginner to this "high tech" forum (equals to, right paranthesis).

 

No Its Lunch time, Im outahere!

 

/Sym

 

Finally someone else who hates graphical smilies!

 

Thankfully there's a checkbox to disable them on this board, and an option in your profile to default to having it checked.

 

What really pisses me off tho is on msn messenger... if you turn off the smilies there you get the text entered as you should... except a lot of the icons dont have a meeningful text representation, so you get (A) for a face with an angel's halo, which should be something like o:-) and you get some truely bizare ones like (}) which I think is ment to represent a hug... never seen the icon for it tho.

 

Anyways, thanks again for the long replies and friendly nature, Im sure I'll enjoy reading more of your insights, stick arround, its a nice board here.