[Java] java.awt.Graphics refreshen (geen Applet)

[JayVee]

Yo!
Ik ben bezig een 3d engine in Java te programmeren. Het moelijkste tot nu toe is helaas de pixels op het scherm te brengen, iets wat zelfs in QBasic zooo makkelijk is.

Heb gesearched, de meeste topics gaan over Applets of de snelheid is niet echt belangrijk. Hier wel!

Maar goed, het probleem:
Ik heb dus een JFrame met daarin een JPanel jp als display. Verder gebruik ik
Graphics g = jp.getGraphics() om het Graphics object te krijgen.
Dan ga ik met g.fillRect( x, y, width, height ) de pixels tekenen.
Werkt prima. Als je maar één plaatje moet tekenen...

Zodra ik hem constant nieuwe frames laat renderen gaat het echt heeeel erg langzaam (en mijn systeem draait Doom III best aardig )...

Op dit moment maakt de engine zodra hij alle pixels klaar heeft een int[][] en stuurt hij deze door naar de renderer. Die pakt dan uit het array (waar alleen "bestaande" pixels in staan) en gaat elk pixel renderen met fillRect.
En dit is dus langzaaaaam.

Oh, en dan blijven zelfs de oude pixels gewoon op het scherm. Als ik ook nog eens elke keer een fillRect over het hele scherm moet trekken om het te "clearen" heeftie meer dan een seconde nodig voor een frame met 16 pixels...

Wie mijn overheerlijke ()code wil zien kan hem hier gezipped downloaden.

Is er een betere manier om plaatjes te tekenen en weer te geven? Misschien niet in awt of zelfs swing maar gewoon in de prompt? In QBasic was dat een kwestie van Screen12 en gaan!

Zou het kunnen dat Java gewoon niet het geschickte platform is om een simpele 3d engine te maken? Raden jullie aan om even de syntax van C++ te leren en daar verder te gaan?

[Nexopheus]

dubbel gebufferde images gebruiken.
Kijk morgen even weer, zal voorbeeld code posten.

!edit: Alhoewel er best redelijke resultaten behaald kunnen worden in Java, is C++ imho hier beter geschikt voor. [qua snelheid dan!]

[ Voor 45% gewijzigd door Nexopheus op 06-03-2003 23:08 ]

[JayVee]

Uhm... ik zie net dat ik een stomme fout gemaakt heb.
Ik wou eens kijken WAT precies nou zo lang duurt. Het refreshen van mijn buffer (die alleen relevante pixels opslaat) heb ik telkens een nieuwe int[buffersize][3] aangemaakt.
buffersize = resolutie_x * resolutie_y
Dus bij 800x600 een flink array ja. STOM STOM STOM.
Nu draait hij erg snel, maar flikkert het beeld een beetje. Is daat nog iets voor te verzinnen?

iig thx voor reactie Nexopoes

[ Voor 4% gewijzigd door JayVee op 06-03-2003 23:20 ]

[Nexopheus]

Tja, die flikkering kun je dus verhelpen met een dubbele buffer, maar aangezien je denkt dat dat de bottleneck is......Zie de code van morgen

[JayVee]

graag!

[Verwijderd]

Het renderen van pixels met behulp van fillRect is ook niet echt optimaal. Verder maak je per pixel een nieuw Color object aan, is ook niet echt nodig.

Volgens mij kan je het beste gebruik maken van een MemoryImageSource. Hiermee kan je met een array van integers, een compleet plaatje beschrijven.
op http://home.planet.nl/~versc436/implicit/ staat een simpel appletje, dat ik heb geschreven, dat gebruik maakt van een MemoryImageSource. Het applet zal waarschijnlijk niet werken (wel als je de source compiled). Helaas is de source niet voorzien van commentaar.

[ Voor 5% gewijzigd door Verwijderd op 07-03-2003 00:54 ]

[Verwijderd]

Maak gebruik van Swing dan ipv AWT. Swing maakt namelijk standaard al gebruik van dubbele buffering

[wasigh]

Zelf DubbelBuffering schrijven mag geen enkel probleem zijn.

Je pakt het Graphics object wat je in je paint krijgt.
Je doet getImage() (oid) en dan getGraphics() op die image.

Op dat Graphics Object doe je al je bewerkingen en dan doe je

g.drawImage(deImageDieJeEerderGeGetHad)

en voila.

Om Pixels in een image te veranderen kun je van je Image een BufferedImage maken, daar een WritabelRaster van verkrijgen en daar op pixel niveau int's wijzigen.

Dit zal allemaal in een goede Java2D boek of tutorial staan

(Java2 game programming is ook een leuk boek waar veel over java games beschreven staat)

[Nexopheus]

De beschrijving van Wasigh is precies de code die ik hier ergens heb. marrre met de beschrijving alleen moet het je ook wel lukken.,!

[JayVee]

Verwijderd schreef op 07 March 2003 @ 00:47:
Het renderen van pixels met behulp van fillRect is ook niet echt optimaal. Verder maak je per pixel een nieuw Color object aan, is ook niet echt nodig.

Dat fillRect idd niet optimaal is snap ik zelf ook wel. Is wel de simpelste methode, aangezien er geen drawPixel of zo is. Daarnaast ben ik pas bezig met enkele punten van 3d (te bewegen) en naar 2d over te zetten. En dan is een pixel erg klein, ik draai namelijk op 1280x1024. Dus nu laat ik hem altijd 4x4 pixels tekenen.

Idd maak ik per pixel een nieuwe kleur aan. Maar dat wil ik voorlopig zo houden, ik kan mijn Pixels namelijk naar een kleur vragen of de engine aanhand van de distance een kleur laten maken. Dat doe ik zo:

Java:

int[] result = new int[3];   // make a new array[3]
int z = 256 - p.getZ();      // distance from camera
result[0] = cam_x + (  ( fov * p.getX() ) / z  ); // calculate 2d x-value
result[1] = cam_y - (  ( fov * p.getY() ) / z  ); // calculate 2d y-value
result[2] = ( z*65536 + z*256 + z*1 );  //make color distance-dependant

Volgens mij kan je het beste gebruik maken van een MemoryImageSource. Hiermee kan je met een array van integers, een compleet plaatje beschrijven.
op http://home.planet.nl/~versc436/implicit/ staat een simpel appletje, dat ik heb geschreven, dat gebruik maakt van een MemoryImageSource. Het applet zal waarschijnlijk niet werken (wel als je de source compiled). Helaas is de source niet voorzien van commentaar.

Uhm... hier snap ik niets van. Ik wil ook geen Applet maken, kan die code ook in een "normaal" java progje?

Verwijderd schreef op 07 maart 2003 @ 00:59:
Maak gebruik van Swing dan ipv AWT. Swing maakt namelijk standaard al gebruik van dubbele buffering

Ik gebruik wel een javax.swing.JFrame en javax.swing.JPanel, maar als ik in die JPanel dan getGraphics doe dan krijg ik een java.awt.Graphics. Hoe moet ik een swing Graphics krijgen die het automatisch doet dan?

wasigh schreef op 07 March 2003 @ 09:43:
§$&{*ö=#ö<|²€

WAT ?
Ik gebruik (nog?) helemaal geen paint. Om de graphics te krijgen doe ik dit:

Java:

public class Display extends JPanel {
  [...]
  public void init () {
    System.out.println("::Display:: initializing...");
    g = getGraphics();
  }
  [...]

Wasigh, kan je misschien ietsie beter uitleggen hoe ik welk image waarvan moet pakken etc? Ik ben niet zo thuis in grafisch java..

Damn, ik dacht dus ff een 3d engine te proggen. Tot nu toe heb ik drie keer zo veel tijd gestopt in het laten zien van wat de engine doet dan in de engine zelf.

[Glimi]

Verwijderd schreef op 07 March 2003 @ 00:59:
Maak gebruik van Swing dan ipv AWT. Swing maakt namelijk standaard al gebruik van dubbele buffering

wasigh schreef op 07 March 2003 @ 09:43:
Zelf DubbelBuffering schrijven mag geen enkel probleem zijn.
(...)

Nexopheus schreef op 07 March 2003 @ 09:55:
De beschrijving van Wasigh is precies de code die ik hier ergens heb. marrre met de beschrijving alleen moet het je ook wel lukken.,!

Ik zie het nut allemaal niet zo

Ik heb dus een JFrame met daarin een JPanel jp als display. Verder gebruik ik
Graphics g = jp.getGraphics() om het Graphics object te krijgen.

Swing buffert zelf al

[Nexopheus]

mmmm maw De graphics van een JPanel oid heeft een andere werking dan een "standaard" awt.Graphics? Hoe gaat dat dan? Volgens mij heeft dat meer te maken met het displayen van widgets in de ContentPane(s).

[wasigh]

JayVee schreef op 07 March 2003 @ 10:35:

Wasigh, kan je misschien ietsie beter uitleggen hoe ik welk image waarvan moet pakken etc? Ik ben niet zo thuis in grafisch java..

Damn, ik dacht dus ff een 3d engine te proggen. Tot nu toe heb ik drie keer zo veel tijd gestopt in het laten zien van wat de engine doet dan in de engine zelf.

Hier ligt denk ik je probleem:

Je wilt ff een 3d engine proggen maar jij bent niet thuis in grafisch java...

verder: je roept een getGraphics aan in een init van een JPanel?
Waarom override je niet gewoon de paint(Graphics g) ??

Dubbelbufferen is niets anders dan eerst tekenen op een offline buffer(Graphics object) en daarna in 1 keer dit object op je beeld zetten. Dit kan met de code die ik hierboven beschreven heb.

Verder kun je wel drawPixel doen. alleen heet die dan setPixel en zit in WritableRaster. Hoe je een WritableRaster kunt verkrijgen heb ik hierboven ook al besproken.

Mijn tip: zoek een goede tutorial of een goed boek:
(Java2 game programming!!! http://oas2000.proxis.be/...LS&mi=3778069&si=33733516)
en ga het allemaal eens rustig bekijken. Probeer eerst een wat thuis te raken in Java2D..

http://www.google.nl/sear...doublebuffering+howto&lr=

[wasigh]

Glimi schreef op 07 March 2003 @ 10:38:

[...]


[...]


[...]


Ik zie het nut allemaal niet zo

[...]
Swing buffert zelf al

Swing componenten wel, maar als je zelf een JPanel override en daar in gaat painten niet meer (is mijn ervaring)

[Nexopheus]

precies, daar heb ik ook mee gezeten.
Verder kun je ipv Paint beter de methode PaintComponent overridden.
LET OP !!!! Dan ook in de overridden methode de super hiervan aanroepen, dus:

Java:

public void PaintComponent(Graphics g){
super.PaintComponent(g);
//Hier je eigen acties op het Graphics object!
}

[Verwijderd]

Ik snap sowiezo niet waarom je van de paint van JPanel gebruik maakt. JPanel is een Container, dus niet een tekenvel... Als je wilt tekenen pak je toch een Canvas

En al wil je het allemaal nog sneller laten gaan schrijf je natuurlijk je eigen Canvas achtige klasse met standaard dubbele buffering

[JayVee]

wasigh schreef op 07 March 2003 @ 11:01:
[...]
Hier ligt denk ik je probleem:

Je wilt ff een 3d engine proggen maar jij bent niet thuis in grafisch java...

Ik had dus gelezen dat het meer wiskunde is dan programmeren. Ik had dus niet verwacht dat het zo "moeilijk" is om in Java wat pixels te tekenen.
Zal ff de tutorials doorlezen.

Voor mensen die de verbeterde en redelijk snelle engine willen zien, kan je hier weer de code downloaden.

Ik zie idd vaker langskomen (ook op andere sites) dat swing automatisch double buffered. Kan iemand ff mijn progje bekijken? De startclasse is engine.GO
Volgens mij gebeurt dat namelijk niet.

[ Voor 19% gewijzigd door JayVee op 07-03-2003 11:32 ]

[JayVee]

wasigh schreef op 07 maart 2003 @ 09:43:
Zelf DubbelBuffering schrijven mag geen enkel probleem zijn.

Je pakt het Graphics object wat je in je paint krijgt.
Je doet getImage() (oid) en dan getGraphics() op die image.

Op dat Graphics Object doe je al je bewerkingen en dan doe je

g.drawImage(deImageDieJeEerderGeGetHad)

en voila.

Okay. Ik had al helemaal geen paint() methode, dat was al niet zo slim vrees ik.

Helaas kan je van de Graphics die je in paint krijgt geen Image trekken.
Ook snap ik niet precies wat er dan precies gebeurt.

Java:

public void updateBuffer ( int[][] buffa, int pixels ) {
    this.buffer = buffa;
    this.no_pixels = pixels;
    repaint();
}

public void paint ( Graphics goo ) {
    backbuffer = getGraphics();
    
    for ( int i = 0; i < no_pixels; i++ ) {
        backbuffer.setColor( new Color(buffer[i][2]) );
        backbuffer.fillRect( (buffer[i][0]-2), (buffer[i][1]-2), 5, 5);
    }
}

Zo. Als de engine klaar is met krijgt dit JPanel uiteindelijk via updateBuffer een nieuwe buffa. Die leg ik vast in de instantievariabele this.buffer. Dan wordt repaint() aangeroepen.

JVM roept dan update en uiteindelijk dus mijn paint aan. Wat is die Graphics goo die ik meekrijg? Is dat de oude Graphics die ik moet gaan wijzigen?
Als dat zo is moet je dus een nieuwe Graphics backbuffer aanmaken en DEZE uiteindelijk met drawImage(backbuffer) laten tekenen? En niets met goo doen?

Heb net de Sun Java AWT tutorial gelezen maar daar wordt ik ook niet wijzer uit. Ze zeggen dat alle Swing dingen idd al double buffered zijn, maar als ik in de classe die het JPanel jp aanmakt jp.isDoubleBuffered aanroep dat returned hij idd true.
Maar het ziet er niet uit!

Doe ik dit ziet het er goed uit maar weet ik dus niet zeker of het wel de juiste manier is:

Java:

public void paint ( Graphics g ) {
    g.setColor( Color.white );      // draw one big grey rectangle
    g.fillRect( 0, 0, res_x, res_y ); // to "clear" the screen

    drawGraph( g );
    
    for ( int i = 0; i < no_pixels; i++ ) {
        g.setColor( new Color(buffer[i][2]) );
        g.fillRect( (buffer[i][0]-2), (buffer[i][1]-2), 5, 5);
    }
}

[ Voor 15% gewijzigd door JayVee op 07-03-2003 13:08 ]

[wasigh]

de g die je meekrijgt is het Graphics object met de inhoud van je JPanel. Je tekent dus direcht op je scherm en daar zit het probleem met het flikkeren.

Je kunt van het Graphics object een nieuw Graphics object maken op de volgende manier:
(de java api-doc is in dit geval natuurlijk je beste vriend: http://java.sun.com/j2se/1.4.1/docs/api/)

http://java.sun.com/j2se/...wt/Graphics.html#create()

(er moet ook een manier zijn om een Image te maken, maar dat kan ik zo snel niet vinden en ik kan ook niet bij mijn code omdat ik nu niet thuis ben)


p.s. Graphics heeft ook een methode clearRect() waarmee je het veld kunt "cleanen"

[ Voor 8% gewijzigd door wasigh op 07-03-2003 13:14 ]

[Verwijderd]

wasigh schreef op 07 March 2003 @ 13:13:
(er moet ook een manier zijn om een Image te maken, maar dat kan ik zo snel niet vinden en ik kan ook niet bij mijn code omdat ik nu niet thuis ben)

BufferedImage bijvoorbeeld, domweg daarop tekenen, en dat plaatje als geheel aanbieden. Dan heb je een gedubbel buffered systeem.

[wasigh]

Ja maar dat kan ook op met gewone Image.

[Verwijderd]

wasigh schreef op 07 March 2003 @ 14:35:
Ja maar dat kan ook op met gewone Image.

dat kan, maar de methodes die Image instanties returnen willen graag een ImageProducer of een andere vorm van een image bron hebben als argument. BufferedImage is bedoeld om nieuwe images te genereren...

[Verwijderd]

Ik ben niet echt thuis in het programmeren van 3D engines maar het leek me altijd dat het niet slim was om swing en awt te mengen. Ik zie bijvoorbeeld dat er Swing componenten gebruikt worden en tegelijkertijd ga je awt gebruiken voor de Graphics stuff.

Ik dacht dat Swing en Awt naast elkaar stonden als een keuze waarvan je 1 van de 2 kiest maar niet beide tegelijk. Swing is namelijk platform onafhankelijk terwijl Awt gebruik zal maken van de bestaande voorzieningen in het besturingssysteem om componenten te renderen. Als je ze dan gaat mengen zal het al snel een warboel worden voor java om bij te houden welke elementen hij in welke volgorde moet beheren.

[Verwijderd]

Dat valt best mee hoor Somey, en zeker als je gebruik maakt van non-visuele componenten maakt het niet veel uit...

[Glimi]

Verwijderd schreef op 07 March 2003 @ 11:15:
Ik snap sowiezo niet waarom je van de paint van JPanel gebruik maakt. JPanel is een Container, dus niet een tekenvel... Als je wilt tekenen pak je toch een Canvas

En al wil je het allemaal nog sneller laten gaan schrijf je natuurlijk je eigen Canvas achtige klasse met standaard dubbele buffering

Sinds waarneer heeft Swing een Canvas? JPanel wordt vaak ervoor gebruikt. Dit omdat JPanel geen container meer is maar net als alle swing objecten containerfunctionaliteit heeft

[Verwijderd]

Glimi schreef op 07 March 2003 @ 15:30:

[...]

Sinds waarneer heeft Swing een Canvas? JPanel wordt vaak ervoor gebruikt. Dit omdat JPanel geen container meer is maar net als alle swing objecten containerfunctionaliteit heeft

Sinds wanneer zeg ik dan dat Canvas een Swing klasse is
Het is een paneel, bedoeld om objecten op te gooien, en daarmee dus geen tekenvel. Oftewel dat ding heeft meer functionaliteit dan je nodig hebt, ik neem aan dat je geen dikke vette swing button over je 3d image heen gooit...

[Verwijderd]

Sinds waarneer heeft Swing een Canvas? JPanel wordt vaak ervoor gebruikt. Dit omdat JPanel geen container meer is maar net als alle swing objecten containerfunctionaliteit heeft

http://java.sun.com/j2se/...i/javax/swing/JPanel.html
Ja een Jpanel IS toch een Container.

[Verwijderd]

je gebruikt een JPanel en dus moet je ook volgens de Swing specificatie tekenen

Java:

public void paintComponent(Graphics g) {
   super.paintComponent(g);
   if(isShowing()) {
      //teken wat gezelligs
   }
}

overerf paintComponent ipv paint, roep z'n papa aan, vergeet de update() methode en repaint door de repaint methode aan te roepen.

[Glimi]

Verwijderd schreef op 07 maart 2003 @ 15:39:
Sinds wanneer zeg ik dan dat Canvas een Swing klasse is

Dus wil je een (AWT)Canvas en JPanel (op een JFrame) gaan mixen (zie topicstart)? Dan zullen de AWT componenten altijd boven weergegeven worden en over de Swing componenten heengetekend worden.

Het is een paneel, bedoeld om objecten op te gooien, en daarmee dus geen tekenvel.

Hoe zie jij Swingobjecten? Waarschijnlijk als een verzameling van Model/View/Controller. Een JPanel heeft echter alleen maar te maken met het View gedeelte. Hij tekent de componenten en klaar is ie. Daarmee vind ik het niet meer dan een tekenvel, welke ook componenten die aan een bepaalde interface (JComponent) voldoen kan tekenen.

Oftewel dat ding heeft meer functionaliteit dan je nodig hebt, ik neem aan dat je geen dikke vette swing button over je 3d image heen gooit...

Vind je ook dat een JComboBox of een JButton te veel functionaliteit heeft? Daar kun je namelijk ook Iconen op tekenen

Verwijderd schreef op 07 maart 2003 @ 15:40:
http://java.sun.com/j2se/...i/javax/swing/JPanel.html
Ja een Jpanel IS toch een Container.

Ik ging idd wat kort door de bocht. Ik bedoelde eerder dat een JPanel als Container niet veel meer doet dan een JButton welke ook (beperkte) container functionaliteiten heeft

[ Voor 15% gewijzigd door Glimi op 07-03-2003 20:51 ]

[JayVee]

Okay!

Heb inmiddels al rotatie gemaakt. Echt 100% tevreden ben ik nog niet met het displayen van het beeld.

De twee meest belangrijke methodes in mijn display classe zijn deze:

Java:

public void updateBuffer ( int[][] buffa, int pixels ) {
  System.out.println( "shibby!");
  this.buffer = buffa;
  this.no_pixels = pixels;
  repaint();
}
  
public void paint ( Graphics g ) {
  g.setColor( Color.white );
  g.fillRect( 0, 0, res_x, res_y );
        
  for ( int i = 0; i < no_pixels; i++ ) {
    g.setColor( new Color(buffer[i][2]) );
    g.fillRect( (buffer[i][0]-2), (buffer[i][1]-2), 5, 5);
  }
}

Wat opvalt is het printen van shibby op lijn 2. Doe ik dat niet dan schokt het erg omdat hij tijdens het updaten al weer de volgende update gaat doen... wat ik eigelijk wil is dat hij zo vaak mogelijk paint maar zo vaak het gaat de nieuwste buffer pakt (duh!).

Ik heb al van deze classe en de classe die deze aanroept (die maakt de buffer staat tussen de 3dcore staat en het display) threads gemaakt maar dat helpt ook niet.

Ik denk dat het iets te maken heeft met synchroniseren, aangezien System.out gesynched is... Heb al geprobeerd binnen updateBuffer synchronize( this ) te gebruiken, maar dat helpt ook niet.

Wie het wil downloaden compilen runnen en zien, be my guest en download het zipje hier!
Starten kan je met engine.GO en het probleem is in classe engine.ui.Display!

Iemand een idee? Thx voor alle reacties hierboven trouwens!!!

[JayVee]

Oh ja. Zoals je aan de code kan zien gebruik ik geen expliciete double buffer. Dat doet idd het java.swing.JPanel al, maar je moet wel de paint methode gebruiken, dat was de stomme fout die ik heb gemaakt. (het eerst niet gebruiken dus... )
Dit hier is een goede bron, maar erg moelijk te vinden vind ik.
http://java.sun.com/produ...icles/painting/index.html

[ Voor 8% gewijzigd door JayVee op 11-03-2003 02:03 ]

[JayVee]

Trapje!

JayVee schreef op 10 March 2003 @ 22:12:
[...]
Wat opvalt is het printen van shibby op lijn 2. Doe ik dat niet dan schokt het erg omdat hij tijdens het updaten al weer de volgende update gaat doen...
[...]
Wie het wil downloaden compilen runnen en zien, be my guest en download het zipje hier!
Starten kan je met engine.GO en het probleem is in classe engine.ui.Display!

Iemand een idee? Thx voor alle reacties hierboven trouwens!!!

[JayVee]

Okay, een keertje nog!
Ik wil dus van die System.out.printlns af. De code is nog steeds te downloaden, check mijn posts voor de url.