Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Is my 2D rasterizer too slow?  (Read 3422 times)
0 Members and 1 Guest are viewing this topic.
Offline csDraco

Junior Newbie




Java games rock!


« Posted 2004-11-27 14:12:59 »

Hi all!  I'm implementing my rasterizer in pure java (1.4) and would like to know if it's performance is way off where it should be for a java software renderer or not.

When I use the 2D draw triangle function, it draws 4000 triangles each frame on my Athlon XP1700 at about 18fps, where each triangle contains 1/2 pixels of a 50x50 pixel square.

Is that too slow and needs to be optimized before I go on any further with an implementation of a software renderer?

Here's some more stats:
1000 tris./frame = 55fps
2000 tris./frame = 32fps
4000 tris./frame = 18fps
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #1 - Posted 2004-11-27 14:40:33 »

Off the top of my head that sounds slow; ISTR doing 25 fps with 4k tris on a p3-450 ish. But maybe I'm being generous to myself and it was only 400 tris Tongue.

But...it depends what you're rendering. Gouraud? Perspective-correct-textures? Both?

Obviously, if you're rendering speed is that low for just plain-old-flat-shading then you're in serious trouble Smiley.

PS is this just for academic interest? Because with 1.4 there's little need for a software rasterizer (if you're requiring 1.4 then the players will already be able to use OpenGL etc; sure, a few people with buggy OGL cards migth love you Grin, but...).

malloc will be first against the wall when the revolution comes...
Offline csDraco

Junior Newbie




Java games rock!


« Reply #2 - Posted 2004-11-27 17:51:30 »

Thanks for replying.
I'm doing this to simply satisfy my academic intrests Smiley.
You mentioned ISTR, is that a java software renderer?  If yes then can you tell me what size were the triangles as this has a huge impact on my 2D resterizer's draw triangle rutine.

If I use smaller triangles 10x10 instead of 50x50 then I can draw 16,000 triangles / frame @ 30fps.

BTW my triangles are 2D & flat shaded ONLY! .. then perhaps it's still hopless performance.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #3 - Posted 2004-11-27 18:45:35 »

I didn't know wtf istr was either.

Sounds like he's using Graphics.drawPolygon().  I'd say doing your own polygon rasterization would always be faster.  But I never stress tested my software renderer before stopping work on it.  So... maybe egonolsen will see this thread.

edit;

Also, something I've been researching lately is hardware rendering pipelines.  I'm thinking copying gpu hardware might lead to greater performance even in java.  

Old school TnL - Translation and Lighting hardware required some tricks that might be optimized by the jit really well.  ie do all your vertex transforms, normal transforms, and lighting calculations in one shot.  Keep state changes to a minimum.  Make everything nice and predictable for the jit compiler and cpu.

Then there are gpu's like the powervr that used some advanced techniques to avoid over draw thus improving fill rate.

For java keep array access at a minumum especially when rasterizing the actual polygons.

After all, when your doing software rendering the cpu is the ultimate programmable gpu.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2004-11-27 19:01:50 »

Quote

BTW my triangles are 2D & flat shaded ONLY! .. then perhaps it's still hopless performance.


That is bad, I'm afraid Sad

Could definitely get thousands of tris @ decent interactive framerates (20-30fps) on 500Mhz machines...

How about you post your tri-rendering code? I'm not guaranteeing I'll look at it (tri-rendering code is often butt-ugly and painful to read through!) but I'll glance it and see how brave I'm feeling...

(nb: there is of course a small chance I'm talking BS; it's been so long since I did a serious attempt at thousands of tris I may be mis-remembering everything. I'm pretty confident, but not 100% Grin)

malloc will be first against the wall when the revolution comes...
Offline csDraco

Junior Newbie




Java games rock!


« Reply #5 - Posted 2004-11-28 01:11:55 »

You asked for it blahblahblah!
My triangle code is quite simple Smiley

I'm concerned about the code that draws scan lines since this is where the worst performance hit is.


Heres my scan line drawing code ...
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
public void setScanLine(int x1, int x2, int y, int color)
{
  // begining and end of the array's indexes that are to be set
  int start, end;
  start = width*((height-1)-y);
  end = start;
  start += x1;
  end += x2;

  for(int i = start; i <= end; i++)
    colorBuffer[i] = color;
}


And here's the triangle code ...
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
public void drawTriangle(int x1, int y1, int x2, int y2, int x3, int y3, int color)
{
    // primary and secondary lines
    RasterLine pl, sl;
    // setup a raster triangle
    triangle.set(x1, y1, x2, y2, x3, y3);
    // perform sorting of points wrt y components
    triangle.sortPoinsByY();
    // update lines of the triangle
    triangle.updateLines();

    // now we can begin working out the scan line intersections

    // first get the priamry and secondary lines
    pl = triangle.l1;
    sl = triangle.l2;
    // check if the primary line is horizontal
    // (remember that the primary line has the gratest dy)
    if(pl.getType() == RasterLine.HORIZONTAL ||
        pl.getType() == RasterLine.POINT)
    {
        // then the whole triangle is a horizontal line
        drawScanLine(pl.x1, pl.x2, pl.y1, color);
    }
    else // we have a non-degenerate (normal) triangle
    {
        // now traverse the y component of the longest line wrt y-axis
        for(int y = triangle.l1.y1; y <= triangle.l1.y2; y++)
        {
          // see if the secondary line is horizontal or if it's end was reached
          if(sl.getType() == RasterLine.HORIZONTAL ||
( y == triangle.l2.y2 && triangle.l3.getType() != RasterLine.HORIZONTAL ))
                sl = triangle.l3;

      // get the x intersection from the primary and secondary lines
      drawScanLine(pl.getX(y), sl.getX(y), y, color);

    }
  }
}


Note that I don't create any new objects in my triangle code.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #6 - Posted 2004-11-28 01:48:24 »

Ah, you're using direct render to buffer. That's probably why it's so slow.

Check / fix your ColorModel so that it matches the screenmode perfectly. Get this right and you get decent speed; get this wrong and you (historically) get huge performance penalties. e.g. if screen is 5550 and you are on 8888 etc. I would have thought this was "fixed" now in the JVM, but...

Try changing your code so that it just does a "drawline" for the scanline, and see what difference it makes; you said you're not doing per-pixel effects, so the render should be identical.

malloc will be first against the wall when the revolution comes...
Offline Absolution

Senior Newbie




Java games rock!


« Reply #7 - Posted 2004-11-28 22:11:55 »

How exactly do they have access to GL without other downloads?

Anyway, I've never done a straight triangle test on my renderer, but I can fill a 500x500 applet with a mutlitextured scene at about 60-70 fps on my P4 2.4.  That jumps to well over 100 fps if I just flat shade it.  Those numbers drop slightly if I use purely 1.1.  I'm not sure if that helps you or not.
Offline csDraco

Junior Newbie




Java games rock!


« Reply #8 - Posted 2004-11-28 22:40:27 »

blahblahblahh:
I did a test where I substitute my own draw triangle for what java provides ( fillPolygon() ), and my fps jumped up from 18fps to 28fps when drawing 4000 triangles per frame ... thant means I'm not way off with my own method Smiley

I'll checkout my color mode now ...


Absolution:
When you draw your scene with flat shaded triangles only, how many traingle do you have in your scene?
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #9 - Posted 2004-11-29 03:35:25 »

Quote
Try changing your code so that it just does a "drawline" for the scanline, and see what difference it makes; you said you're not doing per-pixel effects, so the render should be identical.


It's better to use fillRect for this, it's faster than drawLine.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2004-11-29 07:23:31 »

fillRect should not be faster than drawLine. They should run at exactly the same speed for horizontal and vertical lines. If not then perhaps that's a tweak you could pop in to the next release...

Cas Smiley

Offline Abuse

JGO Knight


Medals: 14


falling into the abyss of reality


« Reply #11 - Posted 2004-11-29 08:09:54 »

I think Java2D is already using that optimisation Cas ('cos 1.4 had a bug where only vertical/horizontal lines would render if alpha acceleration was enabled)
drawLine still has to determine if the line is horizontal/vertical before it can fall back back onto the faster fillRect algorithm. Therefor, calling fillRect directly should still be quicker O_o

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-11-29 13:48:33 »

Pff, yeah, by a cycle or two Smiley

Cas Smiley

Offline nonnus29

Senior Devvie




Giving Java a second chance after ludumdare fiasco


« Reply #13 - Posted 2004-11-29 14:34:24 »

Man I miss the jacc; we should organize an applet rendering challenge or something...
Offline crystalsquid

Junior Devvie




... Boing ...


« Reply #14 - Posted 2004-11-29 18:58:17 »

Is the performance too slow... for what?

As long as your scenes render > 20fps on the target spec, then its probably fast enough Smiley
Offline csDraco

Junior Newbie




Java games rock!


« Reply #15 - Posted 2004-11-29 20:08:30 »

Quote
Is the performance too slow... for what?

As long as your scenes render > 20fps on the target spec, then its probably fast enough Smiley


Good point!
Perhaps I'm waisting my time optimizing when I don't even have a scene yet.
Offline trembovetski

Senior Devvie




If only I knew what I'm talking about!


« Reply #16 - Posted 2004-11-30 02:10:30 »

Quote
fillRect should not be faster than drawLine. They should run at exactly the same speed for horizontal and vertical lines. If not then perhaps that's a tweak you could pop in to the next release...


The difference is at least two checks.
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2004-11-30 07:06:04 »

If Hotspot's doing it's job correctly it should inline the call and then it should completely eliminate the checks if the values are the same or constant shouldn't it...?

Cas Tongue

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #18 - Posted 2004-11-30 09:01:54 »

FWLIW there was no noticeable difference on 1.2.x when I was profiling over the course of one hundred frames or so, the last time I bothered to measure the difference. Maybe the difference is simply so small that it disappears on such a short test? I don't think I ever bothered micro-benchmarking.

IIRC it also optimized repeated drawlines with a single pixel into a line (ISTR reading about this some years later - the fact that the Graphics does coalescing and/or re-ordering of some calls in order to do batch processing and avoid unnecessarily invalidating the pipeline?) - but it was a long time ago, so maybe my memory's rusty Smiley.

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #19 - Posted 2004-11-30 10:58:50 »

That would be a very silly optimisation indeed.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #20 - Posted 2004-11-30 11:26:10 »

Quote
That would be a very silly optimisation indeed.


Why?

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #21 - Posted 2004-11-30 12:22:16 »

There is no possible way that checking that a bunch of dots sent down a pipeline is in fact a line without totally buggering the pipeline. Try it from a client/server OpenGL point of view, you'll see what I mean. The server is in charge of drawing but it can't know from one minute to the next what the client is going to send to it. And the bottleneck is the bus between them, not the drawing.

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #22 - Posted 2004-11-30 12:35:20 »

Quote
There is no possible way that checking that a bunch of dots sent down a pipeline is in fact a line without totally buggering the pipeline. Try it from a client/server OpenGL point of view, you'll see what I mean. The server is in charge of drawing but it can't know from one minute to the next what the client is going to send to it. And the bottleneck is the bus between them, not the drawing.

Cas Smiley


From a C/S POV you typically *would* put a post-processor on the client side which checks successive requests and does whatever batching/compression it can Smiley (like Nagle'ing, for instance).

/me trying to find original sources in bookmarks; failed; trying to find stuff on google...

http://weblogs.java.net/blog/chet/archive/2004/09/tiger_on_the_de_1.html
Quote

There were fixes in some rendering niches that are worth mentioning:

   *

     Primitive batching on Windows: we are smarter now about how we batch up line rendering calls when using our Direct3D renderer on Windows. This reduced the (significant) overhead per line and got us up to a 10x improvement in micro benchmarks (your mileage will vary; the biggest improvement will be seen when you issue all line calls together, not interspersed with other types of rendering operations).


http://java.sun.com/j2se/1.3/docs/guide/2d/spec/j2d-awt.fm2.html
Quote

   Batch Processing

   To streamline the processing of pixels, the Java 2D API processes them in batches. A batch can be either a contiguous set of pixels on a given scanline or a block of pixels. This batch processing is done in two steps:

      1. The Paint object's createContext method is called to create a PaintContext. The PaintContext stores the contextual information about the current rendering operation and the information necessary to generate the colors. The createContext method is passed the bounding boxes of the graphics object being filled in user space and in device space, the ColorModel in which the colors should be generated, and the transform used to map user space into device space. The ColorModel is treated as a hint because not all Paint objects can support an arbitrary ColorModel. (For more information about ColorModels, see "Color".")
      2. The getColorModel method is called to get the ColorModel of the generated paint color from the PaintContext.

   The getRaster method is then called repeatedly to get the Raster that contains the actual color data for each batch. This information is passed to the next stage in the rendering pipeline, which draws the generated color using the cu rrent Composite object.


Still not found the original doc(s) where I read about it (it would hepl if I could remember what it/they were, but I can only say "i'll recognise them when I see 'em").

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 434
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2004-11-30 13:39:45 »

It's no wonder the API's so bloody slow, unreliable and complicated.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (30 views)
2014-12-15 09:26:44

Mr.CodeIt (22 views)
2014-12-14 19:50:38

BurntPizza (42 views)
2014-12-09 22:41:13

BurntPizza (76 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (51 views)
2014-12-03 16:27:13

CopyableCougar4 (49 views)
2014-11-29 21:32:03

toopeicgaming1999 (115 views)
2014-11-26 15:22:04

toopeicgaming1999 (105 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!