Symmetry of TNG wrote:
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:
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)
(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)
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)
And Thunderbirds reply:
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.
Original thread:http://atariage.com/forums/topic/19187- ... nt-voxels/