[java] probleem met multithreading :?

[almightyarjen]

Ik, een beginnende Java doe-het-zelver, probeer een Java Applet te schrijven waarin in het begin een bal heen en weer stuiterd en na een muisklik moet er een bal bij komen... Nou, 1 bal is geen probleem, maar de tweede krijg ik er niet bij. Ik ben nu zo ver dat 1 bal het gewoon goed doet, maar zodra ik op de muis klik, gaat de bal sneller ipv dat er een bal bij komt. Ik heb een sterk vermoeden dat dit ligt aan dat elke thread dezelfde repaint() aanvraagt... Maar hoe precies snap ik niet helemaal... Anyone? Zit al een week op dit vraagstuk te zweten... Hieronder zal ik ff de tot nu toe gemaakte sourcecode plaatsen:

code:

import java.awt.*;
import java.awt.event.*;
import java.applet.*;

public class Ball5 extends Applet implements Runnable 
{
  int x,y,dx,dy,diam,sizex,sizey; 
  
  public void init() 
  {
    setBackground(Color.black);
    x=y=0; dx=dy=5; diam=20;
    sizex=Integer.parseInt(getParameter("WIDTH"));
    sizey=Integer.parseInt(getParameter("HEIGHT"));
    addMouseListener( new MouseClickHandler() );
    (new Thread(Ball5.this)).start();
  }

  public void run() 
  {
    while (true) 
    {
      try 
      {
        Thread.currentThread().sleep(40);
      }
      catch (InterruptedException e) {};
      x+=dx; y+=dy;
      if ((x<=0)||(x+dx+diam>=sizex)) dx=-dx;
      if ((y<=0)||(y+dy+diam>=sizey)) dy=-dy;
      repaint();
    }
  }

  public void paint(Graphics g) 
  {
    g.setColor(Color.white);
    g.fillArc(x,y,diam,diam,0,360);
  }

  private class MouseClickHandler extends MouseAdapter 
  {
    public void mouseClicked( MouseEvent e )
    {
    (new Thread(Ball5.this)).start(); 
    }
  }
}

Ik kan trouwens de applet zelf niet online zetten, omdat de compiler een bestand genereerd, waar een $ in staat, dat pikt tripod e.d. niet...

[NDF82]

Dat komt omdat je geen tweede bal aanmaat, je geeft dezelfde(Ball5.this) mee aan de Thread.

[almightyarjen]

NDF82 schreef op 20 november 2002 @ 14:31:
Dat komt omdat je geen tweede bal aanmaat, je geeft dezelfde(Ball5.this) mee aan de Thread.

Zo'n nat gevoel had ik al... Hoe uh, hoe moet dat precies?

[whoami]

code:

Nieuwebal = new Bal();

[NDF82]

code:

public class Arena extends Applet {
    private Rectangle _arena = new RectAngle(50, 50, 200, 100);
    private Ball[]    _balls = {};      

    ...
    
    public void init() {
        _balls = new Ball[] { new Ball(_arena), new Ball(_arena)};
    }
    
    public void paint(Graphics g) {
        g.drawRect(_arena);
        for (int i = 0; i< _balls.lenght; i++) {
            g.drawOval(_balls[i].getX(), _balls[i].getY(), 10, 10);
        }
    }
}

class Ball extends Thread {
    private Rectangle _bounds;
    
    private int x;
    private int y;
    
    public Ball(Rectangle bounds, int speed) {
        _bounds = bounds;
    }
    
    
    public void run() {
        //doe hier collision detection en updaten van x en y
    }
    
    
    ...
}

jij moet de rest invullen

[Alarmnummer]

Aha... vraagje NDF82. Weet je wat concurrency control is? Zo nee, then del *.java Zo ja, then del *.java.

Oplossing voor jouw probleem. Zorg dat je ball niet van Thread laat extenden. Je moet gewoon een hele lading ballen maken en die in een lijst achtige structuur plaatsen. Je maakt dan een Timer die om de x ms alle ballen aanroept en eventueel een collision detection uitvoerd. Hierdoor heb je niets meer te maken met concurrency control.

PS: alle methodes dan maar synchronized maken zorgt voor hele leuke effecten. Ballen die ineens stil blijven staan ed.

[bazzs2001]

Alarmnummer schreef op 20 November 2002 @ 15:01:
Aha... vraagje NDF82. Weet je wat concurrency control is? Zo nee, then del *.java Zo ja, then del *.java.

NDF's plan moet toch gewoon werken? Niet zo efficent misschien maar het moet wel werken.

Oplossing voor jouw probleem. Zorg dat je ball niet van Thread laat extenden. Je moet gewoon een hele lading ballen maken en die in een lijst achtige structuur plaatsen. Je maakt dan een Timer die om de x ms alle ballen aanroept en eventueel een collection detection uitvoerd. Hierdoor heb je niets meer te maken met concurrency control.

En dit plan is beter, maar dat maakt NDF's plan toch niet gelijk fout?

[Alarmnummer]

Als je collision detection gaat doen, dan moet je ook bij andere ballen komen. Maak je geen gebruik van synchronisatie dan kan het gebeuren dat je verkeerde gegevens binnenkrijgt. Plaats je overal synchronized voor (wat 99% van de mensen zien als concurrency control) dan krijg je onheroepelijk deadlocks.

[NDF82]

Uit z'n verhaal kan ik alleen opmaken dat ie z'n ballen in een box wil laten rondstuiteren, er staat nergens dat ze elkaar niet mogen aanraken, overlappen, whatever...

Duszzzz, van deadlocks zal hij dan geen last hebben hoor.

[Alarmnummer]

NDF82 schreef op 20 november 2002 @ 15:23:
Uit z'n verhaal kan ik alleen opmaken dat ie z'n ballen in een box wil laten rondstuiteren, er staat nergens dat ze elkaar niet mogen aanraken, overlappen, whatever...

Duszzzz, van deadlocks zal hij dan geen last hebben hoor.

Ik zie inderdaad dat jij die fout maakte en niet hij.

[NDF82]

Welke fout maakte ik? Wat versta jij eigelijk onder collision detection? ALs twee ballen tegen elkaar komen is er een "botsing", maar zodra ie tegen een muur (de box in dit geval) komt is het geen "botsing"?? Rare eend ben jij

[Alarmnummer]

NDF82 schreef op 20 November 2002 @ 15:33:
Welke fout maakte ik?

Dat je onheroepelijk om concurrency control problemen gaat vragen met jouw aanpak.

Wat versta jij eigelijk onder collision detection? ALs twee ballen tegen elkaar komen is er een "botsing", maar zodra ie tegen een muur (de box in dit geval) komt is het geen "botsing"?? Rare eend ben jij

De muur die veranderd niet, en immutable objecten hoef je gelukkig niets lastig mee te doen ivm concurrency control. En geef verder eens wat betere argumenten want dit raakt ook kant nog wal.

[NDF82]

De muur die veranderd niet, en immutable objecten hoef je gelukkig niets lastig mee te doen ivm concurrency control. En geef verder eens wat betere argumenten want dit raakt ook kant nog wal.

je zegt het zelf al, de muur veranderd niet. De Thread hoeft toch nergens op te wachten (lees: wait()) dus hoe kun je dan een Deadlock krijgen???

[Alarmnummer]

NDF82 schreef op 20 november 2002 @ 15:40:
[...]


je zegt het zelf al, de muur veranderd niet. De Thread hoeft toch nergens op te wachten (lees: wait()) dus hoe kun je dan een Deadlock krijgen???

Als 2 ballen elkaar willen benaderen. Dan kan het voorkomen dat bal1 bal2 al heeft gelocked en later bal 2 bal1 wil locken => deadlock.

[bazzs2001]

Alarmnummer schreef op 20 november 2002 @ 15:43:
[...]


Als 2 ballen elkaar willen benaderen. Dan kan het voorkomen dat bal1 bal2 al heeft gelocked en later bal 2 bal1 wil locken => deadlock.

ze willen elkaar toch niet locken???
ze hoeven toch niet van elkaars bestaan af te weten

[NDF82]

true, maar dat is hier toch niet van toepassing, hij heeft alleen een box waarop ie controleert..

edit: Bazzs is me voor ZZZzzzzz

[Alarmnummer]

Als ze alleen op de muur hoeven te checken dan is dat idd niet nodig, maar als je wilt controleren of 2 ballen elkaar raken dan moeten ze wel van elkaar bestaan afweten.

[bazzs2001]

Alarmnummer schreef op 20 november 2002 @ 15:01:

PS: alle methodes dan maar synchronized maken zorgt voor hele leuke effecten. Ballen die ineens stil blijven staan ed.

deadlocks leuk? ;-)

[bazzs2001]

Alarmnummer schreef op 20 november 2002 @ 15:47:
Als ze alleen op de muur hoeven te checken dan is dat idd niet nodig, maar als je wilt controleren of 2 ballen elkaar raken dan moeten ze wel van elkaar bestaan afweten.

dan moet je het helemaal niet met 1 thread per bal gaan doen, das vragen om moeilijkheden. maar hier niet het geval

[Alarmnummer]

Nee, deadlock zijn vervelend en threads eigelijk ook. Ik probeer als het enigsinds kan ze (vooral de 1e ) zoveel mogelijk te vermijden. Concurrency control is niet iets wat je er even in plakt, maar wat structureel in je ontwerp komt te zitten. Vooral rekening houden met deadlocks ed maakt concurrency control tot iets uitermate gecomliceerds.

[bazzs2001]

Alarmnummer schreef op 20 November 2002 @ 15:50:
Nee, deadlock zijn vervelend en threads eigelijk ook. Ik probeer als het enigsinds kan ze (vooral de 1e ) zoveel mogelijk te vermijden. Concurrency control is niet iets wat je er even in plakt, maar wat structureel in je ontwerp komt te zitten. Vooral rekening houden met deadlocks ed maakt concurrency control tot iets uitermate gecomliceerds.

threads vervelend??? die moet je even uitleggen,
ik ben juist blij met de multi threading mogelijkheden die java biedt (Thread klasse enzo)

Je moet inderdaad wel altijd rekening houden met "concurrency control", maar das niet altijd lastig.

[Alarmnummer]

Ik heb ook geen klachten over java mbt threads. Maar eerder over concurrency control in het algemeen. Vooral om te garanderen dat je systeem geen deadlocks bevat vind ik een uitermate lastige zaak.

Ik ben verder wel thuis in de materie, maar hoe meer ik er over lees, hoe huiveriger ik er eigelijk tegen begin te worden.

[Donderwolk]

Ik ben verder wel thuis in de materie, maar hoe meer ik er over lees, hoe huiveriger ik er eigelijk tegen begin te worden.

Hoeft niet hoor. Heb je niet zo'n mooie handige busyflag klasse? Daarmee wordt het inbouwen van concurrency een stuk gemakkelijker.

[Alarmnummer]

Kan je eens een voorbeeld geven?

[Donderwolk]

Ja is goed zal ze zometeen posten als ik thuis kom.
(Ben nu nog even heeeeel hard aan het werk )

[Alarmnummer]

*heeft een vaag voorgevoel dat het niets anders is dan een mutex object*

En iedereen kan alles zo maken dat je niet op 1 tijd stip, op 1 resource meerdere prrocessen werken. Maar om een systeem deadlock vrij te maken is echt hele andere koek.

[wacco]

almightyarjen schreef op 20 November 2002 @ 14:27:
Ik, een beginnende Java doe-het-zelver, probeer een Java Applet te schrijven waarin in het begin een bal heen en weer stuiterd en na een muisklik moet er een bal bij komen...

Hmm... almightyarjen, klinkt nogal als het balletjes voorbeeld uit 'En dan is er... Java, 2e versie' van gertjan laan. En dan is de extra opdracht (leraar JDR of JKR, right?) voor blok 2 programmeren practicum binnen PMB voor week 6 dat je een animatie neemt (jij neemt dus gewoon de animatie uit het boek over...) en dat je met een druk van de muisknop een animatie (nieuwe thread) erbij krijgt.

doe-het-zelver?

FAQ over huiswerk, en let dan vooral eens op de laatste regel...

[Donderwolk]

Goed ben nu thuis:
Even kijken een semafoor klasse:

code:

public class Semaphore{
  private int s;

  public Semaphore(int i){
    s = i;
  }

  public synchronized void P(){
    while (s == 0){
      try{
        wait();
      }
      catch(Exception e) {}
    }
    s--;
  }

  public synchronized void V(){
    s++;
    notify();
  }
}

[Donderwolk]

En een busyflag klasse:

code:

// Bron: Oaks & Wong: Java Threads 2nd Edition
public class BusyFlag {
    protected Thread busyflag = null;
    protected int busycount = 0;

    public void getBusyFlag() {
        while (tryGetBusyFlag() == false) {
            try {
                Thread.sleep(100);
            } catch (Exception e) {}
        }
    }

    public synchronized boolean tryGetBusyFlag() {
        if (busyflag == null) {
            busyflag = Thread.currentThread();
            busycount = 1;
            return true;
        }
        if (busyflag == Thread.currentThread()) {
            busycount++;
            return true;
        }
        return false;
    }

    public synchronized void freeBusyFlag () {
        if (getBusyFlagOwner() == Thread.currentThread()) {
            busycount--;
            if (busycount == 0)
                busyflag = null;
        }
    }

    public synchronized Thread getBusyFlagOwner() {
        return busyflag;
    }
}

[Donderwolk]

Alarmnummer schreef op 20 November 2002 @ 16:14:
*heeft een vaag voorgevoel dat het niets anders is dan een mutex object*

En iedereen kan alles zo maken dat je niet op 1 tijd stip, op 1 resource meerdere prrocessen werken. Maar om een systeem deadlock vrij te maken is echt hele andere koek.

Die busyflag is inderdaad een mutex. De semafoor klasse kan ook dienen als mutex maar biedt wel de mogelijkheid om een duidelijke structuur in het aanroepen en vrijgeven van processen beter te besturen. Om dus gemakkelijker een deadlock te kunnen voorkomen. Het is hierbij wel zaak dat de .p() en .v() methoden evenvaak zullen moeten worden aangeroepen. (dus 2x p() zal moeten worden gevolgd door 2x v() ). Doe je dit goed dan zul je in veel gevallen in staat zijn om een deadlock te voorkomen.

[Alarmnummer]

Ik wil niets zeggen hoor (eigelijk wel, want anders maakte ik deze reply niet), semaphoren zijn voor een gedeelte te vervangen door monitoren omdat je bij semaphoren gewoon meer fout kan doen.

En daarnaast is de code voor een deadlock in principe ook wel correct en ligt dus niet aan het feit dat je een up of down ofzo bent vergeten.

Zoals ik al zei: een deadlock vrij systeem maken is echt hele andere koek dan ondeelbare operaties te maken hoor.

[Donderwolk]

Met behulp van deze twee klassen ben ik altijd nog in staat geweest om een deadlock vrij systeem te maken. En 't was echt een piece of koekje

[Alarmnummer]

simpel voorbeeld van 'correcte' code met een lieve deadlock.
(Concurrent Programming in Java - Doug Lea)

Java:

class Cell{
    private int _value;

    public synchronized int getValue(){return _value;}

    public synchronized void setValue(int value){_value = value;}

    public synchronized void swap(Cell other){
         int t = getValue();
         int v = other.getValue();
         setValue(v);
         other.setValue(t);
    }
}

[kenneth]

Tot je een keertje twee V()'s in een omgekeerde volgorde doet ... Erg lastig als zich dat buiten een method uitstrekt.

edit:
Hey almigthyarjen nie zo snel!

[Alarmnummer]

mithalph schreef op 20 november 2002 @ 17:09:
Tot je een keertje twee V()'s in een omgekeerde volgorde doet ... Erg lastig als zich dat buiten een method uitstrekt.

Zoals ik al eerder heb gezegd. Deadlocks hebben niets te maken incorrect uppen en downen van semaforen. Een monitor is over het algemeen een in een taal ingebouwde vervanging van een semafoor. En je kan dus een java object dus zien als een monitor mits je zijn methodes maar synchronized maakt. Doordat de computer nu voor jou alle 'up en downs' doet kan je niet per ongeluk iets vergeten. Maar ook monitoren zijn gevoelig voor deadlocks.

[Donderwolk]

Leuk voorbeeld. Je kan op je vingers al natellen dat je een deadlock krijgt
In principe zijn deadlocks inderdaad moeilijk te verhelpen. In je ontwerp zal je dan ook alvast goed rekening moeten houden waar je deadlocks kunt verwachten.
Ik denk dat mutexen en semaforen in ieder geval een goede oplossing zijn om deadlocks en race conditions te voorkomen.

Mijn Java Threads boek zegt hierover:
Preventing deadlock is completely the responsibility of the Java developer....

[almightyarjen]

wacco schreef op 20 november 2002 @ 16:14:
[...]


Hmm... almightyarjen, klinkt nogal als het balletjes voorbeeld uit 'En dan is er... Java, 2e versie' van gertjan laan. En dan is de extra opdracht (leraar JDR of JKR, right?) voor blok 2 programmeren practicum binnen PMB voor week 6 dat je een animatie neemt (jij neemt dus gewoon de animatie uit het boek over...) en dat je met een druk van de muisknop een animatie (nieuwe thread) erbij krijgt.

doe-het-zelver?

FAQ over huiswerk, en let dan vooral eens op de laatste regel...

Dit is een hele normale opdracht, en idd ik heb hem uit een boek. Verschil is alleen dat ik mezelf wat java aan het bijleren ben, het is niet voor school... Op het internet komt deze opdracht ook in vele varianten voor.

Maaruh, ik snap er nog steeds geen hole van hoor... Synchronized threads, collision detection... allemaal niet nodig. Ik wil het eerst eens voor elkaar krijgen om twee balletjes te zien bewegen... Heeft iemand niet een simpeler voorbeeld? Ik heb het gevoel dat ik er wel dicht bij ben...

[ACM]

[.oisyn vraagt het duidelijker ]

almightyarjen schreef op 20 November 2002 @ 17:56:
Maaruh, ik snap er nog steeds geen hole van hoor... Synchronized threads, collision detection... allemaal niet nodig. Ik wil het eerst eens voor elkaar krijgen om twee balletjes te zien bewegen... Heeft iemand niet een simpeler voorbeeld? Ik heb het gevoel dat ik er wel dicht bij ben...

Hierboven geeft Alarmnummer al een aardige tip: [rml]Alarmnummer in "[ java] probleem met multithreading :?"[/rml]
Tweede alinea daarvan.

[.oisyn]

Alarmnummer schreef op 20 November 2002 @ 17:06:
simpel voorbeeld van 'correcte' code met een lieve deadlock.
(Concurrent Programming in Java - Doug Lea)

Java:

class Cell{
    private int _value;

    public synchronized int getValue(){return _value;}

    public synchronized void setValue(int value){_value = value;}

    public synchronized void swap(Cell other){
         int t = getValue();
         int v = other.getValue();
         setValue(v);
         other.setValue(t);
    }
}

waarom deadlocked dit?
de huidige thread krijgt de monitor van de huidige Cell, daar doet ie een getValue () op, dan vraagt ie ook nog eens de monitor van de andere Cell, daar doet ie wederom een getValue () op, geeft die monitor weer terug, dan setValue () op deze (de monitor had ie al), dan setValue () op die andere (weer een monitor opvraag en teruggave), en dan geeft ie vervolgens de monitor van deze Cell weer terug

tenzij 2 threads dit op precies hetzelfde moment doen natuurlijk, maar uit je verhaaltje dacht ik (misschien ten onrechte) min of meer de halen dat dit altijd gegarandeerd een deadlock gaf

[almightyarjen]

ACM schreef op 20 november 2002 @ 18:05:
[.oisyn vraagt het duidelijker ]


[...]

Hierboven geeft Alarmnummer al een aardige tip: [rml]Alarmnummer in "[ java] probleem met multithreading :?"[/rml]
Tweede alinea daarvan.

Ja, voor zover ik het begrijp is dat een manier ja... Maar het moet toch ook kunnen met concurrency? De opdracht staat lijkt mij niet voor niets in het hoofdstuk multithreading...

[Donderwolk]

.oysin: Ja en probeer dit nu maar eens met meerdere threads...

[ACM]

almightyarjen schreef op 20 november 2002 @ 18:13:
Ja, voor zover ik het begrijp is dat een manier ja... Maar het moet toch ook kunnen met concurrency? De opdracht staat lijkt mij niet voor niets in het hoofdstuk multithreading...

Tuurlijk, je kan ook alle ballen een losse thread (de interface Runnable implementeren bijv) geven en dan laten verplaatsen via de run methode oid.

En als je ze alleen wilt laten verplaatsen, moet je eerst nog niet moeilijk met collision detection doen en simpelweg ze rond laten gaan op je scherm.
Dat laatste gebeurd natuurlijk door de graphics library, maar de positionering zou je dmv Threading dynamisch onafhankelijk van de applet zelf kunnen doen.

Echter als je het perfect wilt doen, dan zul je ze moeten laten controleren dat ze niet door een andere bal heen gaan
En dan is locking opzich wel handig

Enige nadeel is dus deadlocking.
Overigens zou je dat met een bal-tabel oid op kunnen lossen waar je in bijhoudt hoe groot elke bal is en waar ie is. Dan krijg je hooguit dat je ballen lang moeten wachten tot ze een lock op die tabel kunnen krijgen, maar deadlocking lijkt me er wel mee te voorkomen.

[.oisyn]

De oplossing zoals het hoort (lees: zoals over het algemeen geimplementeerd in simulaties en spellen) is 1 GUI thread (die bestaat dus al, die roept je init () methode aan) en een worker thread, in die worker thread beweeg je per stap alle ballen en doe je daar collision detection op (al dan niet met elkaar)

[Donderwolk]

Ja dat ben ik met .oisyn eens zo kun je later ook gemakkelijk dubbele buffering implementeren mocht dat nog nodig blijken.

[Alarmnummer]

.oisyn schreef op 20 november 2002 @ 18:06:
tenzij 2 threads dit op precies hetzelfde moment doen natuurlijk, maar uit je verhaaltje dacht ik (misschien ten onrechte) min of meer de halen dat dit altijd gegarandeerd een deadlock gaf

Ik had er misschien idd beter bij kunnen zetten dat er meerdere threads actief waren. Maar dat leek me gezien de strekking van dit topic wel vrij duidelijk

[Donderwolk]

ja anders had het net zo goed niet synchronized hoeven zijn

Maar goed ik had het ongeveer zo gedaan: (Heb nog niet kunnen testen en nog geen collision detection op ballen)

code:

import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import java.util.*;

public class Bouncy extends Applet implements Runnable
{ 
  boolean shouldRun = true;
  Vector ballen = new Vector();
  int width = 0;
  int height = 0;
  
  public void init() 
  {
    setBackground(Color.black);
    //x=y=0; dx=dy=5; diam=20;
    width=Integer.parseInt(getParameter("WIDTH"));
    height=Integer.parseInt(getParameter("HEIGHT"));
    addMouseListener( new MouseClickHandler() );
    (new Thread(Bouncy.this)).start();
  }

  public void run() 
  {
    while (shouldRun) 
    {
      try 
      {
        Thread.currentThread().sleep(40);
      }
      catch (InterruptedException e) {};
      repaint();
    }
  }

  public void paint(Graphics g) 
  {
    for ( int i=0; i<ballen.size(); i++ ){
      Ball tempBal = (Ball) ballen.elementAt[i];
      tempBal.moveBall();
      tempBal.drawBall( g );
    }
  }

  private class MouseClickHandler extends MouseAdapter 
  {
    public void mouseClicked( MouseEvent e )
    {
      ballen.add( new Ball(15,15,5,3,20,width,height) ); 
    }
  }
  public class Ball{
    int x=0,y=0,dx=0,dy=0,diam=0,sizex=0,sizey=0;

    public Ball(int x, int y, int dx, int dy, int diam, int sizex, int sizey){
      this.x = x;
      this.y = y;
      this.dx = dx;
      this.dy = dy;
      this.diam = diam;
      this.sizex = sizex;
      this.sizey = sizey;          
    }

    public void moveBall(){
      x+=dx; y+=dy;
      if ((x<=0)||(x+dx+diam>=sizex)) dx=-dx;
      if ((y<=0)||(y+dy+diam>=sizey)) dy=-dy;
    }

    public void drawBall( Graphics g ){
      g.setColor(Color.white);
      g.fillArc(x,y,diam,diam,0,360);
    }
  }
}

[ACM]

Donderwolk schreef op 20 november 2002 @ 18:51:
ja anders had het net zo goed niet synchronized hoeven zijn

Maar goed ik had het ongeveer zo gedaan: (Heb nog niet kunnen testen en nog geen collision detection op ballen)

Is dan weer wel een beetje single threaded

[kenneth]

Donderwolk schreef op 20 November 2002 @ 18:51:

code:

      Ball tempBal = (Ball) ballen.elementAt[i];

Moet natuurlijk zijn:

Java:

Ball tempBal = (Ball) ballen.elementAt(i);

Ennuh, het werkt hoor

[almightyarjen]

Dank jullie allen! Even een aantal vragen nog:

code:

 public void paint(Graphics g) 
  {
    for ( int i=0; i<ballen.size(); i++ ){
    Ball tempBal = (Ball) ballen.elementAt(i);
      tempBal.moveBall();
      tempBal.drawBall( g );
    }

Bij het for-statement: i<ballen.size() Hier moet i kleiner zijn dan

ennuh:

code:

 public Ball(int x, int y, int dx, int dy, int diam, int sizex, int sizey){
      this.x = x;
      this.y = y;
      this.dx = dx;
      this.dy = dy;
      this.diam = diam;
      this.sizex = sizex;
      this.sizey = sizey;          
    }

Wat gebeurt hier precies?

[Alarmnummer]

almightyarjen schreef op 20 november 2002 @ 19:55:


Dank jullie allen! Even een aantal vragen nog:

code:

 public void paint(Graphics g) 
  {
    for ( int i=0; i<ballen.size(); i++ ){
    Ball tempBal = (Ball) ballen.elementAt(i);
      tempBal.moveBall();
      tempBal.drawBall( g );
    }

Bij het for-statement: i<ballen.size() Hier moet i kleiner zijn dan

Het is geen pascal Tel maar na.


ennuh:

code:

 public Ball(int x, int y, int dx, int dy, int diam, int sizex, int sizey){
      this.x = x;
      this.y = y;
      this.dx = dx;
      this.dy = dy;
      this.diam = diam;
      this.sizex = sizex;
      this.sizey = sizey;          
    }

Wat gebeurt hier precies?[/quote]
Lijkt verdacht veel op zo`n constructor thingy Ze schijnen al een tijdje te bestaan in oo land

[Reefer]

almightyarjen schreef op 20 November 2002 @ 19:55:
Bij het for-statement: i<ballen.size() Hier moet i kleiner zijn dan

de grootte van de array, oftewel de size()

Wat gebeurt hier precies?

de argumenten worden in de instancevariabelen gezet, en omdat die dezelfde naam hebben kun je er this. voorzetten om aan tegeven dat je de variabelen van de class bedoelt.

[Donderwolk]

Hoe zit het met de schermopbouw? Flikkert het scherm ook?
Heb nog niks kunnen testen dus ben wel even benieuwd. Misschien wel leuk om ook nog even een random in het opstarten van de ballen in te bouwen

[Donderwolk]

Bij het for-statement: i<ballen.size() Hier moet i kleiner zijn dan

i moet dus kleiner zijn als de grootte van je kloten
beetje triviaal inderdaad...

[almightyarjen]

Alarmnummer schreef op 20 november 2002 @ 19:56:
[...]

Het is geen pascal Tel maar na.

Tja, Pascal is en blijft mijn basis....

[Alarmnummer]

almightyarjen schreef op 20 november 2002 @ 20:38:
[...]


Tja, Pascal is en blijft mijn basis....

Pascal/delphi 1.. n
c/java/c#/c++ 0..n-1

Dit komt omdat vroeger bij c met pointer berekening het adres heel eenvoudig bepaald kon worden door offset+n*size_structure. Vandaar zero based. Java c en c++ zijn daar allemaal weer van afgeleid. Pascal daarintegen is gemaakt om studenten te leren programmeren, en dan is het logischer om te spreken over het 1e element ipv het nulde.

Het is gewoon even wennen, maar dat gaat snel genoeg *heeft vroeger ook in pascal geprogged*

[almightyarjen]

* almightyarjen vindt Java maar een schijttaal, maar wil er toch iets meer van weten... Thanx voor de hulp anyways

[kenneth]

Donderwolk schreef op 20 November 2002 @ 20:04:
Hoe zit het met de schermopbouw? Flikkert het scherm ook?
Heb nog niks kunnen testen dus ben wel even benieuwd. Misschien wel leuk om ook nog even een random in het opstarten van de ballen in te bouwen

Nope, geen flikkers, alles lekker
Ik met m'n domme hoofd had de source niet gelezen. Dus ik dacht Hey geen balletjes. *Klik*

Ohja JDK1.4.0 in case you wanted to know...

Nou, gelijk maar op sf.net gooien?

"Bouncy is an open-source, single-threaded, powerful and extensible ball bouncer. Please note that the value of i must be less than the size of your balls."


Sorry, ik ga al naar bed

[almightyarjen]

Euh, nog 1 vraag: de applet doet het wel goed als je hem laadt met appletviewer, maar als je de htm laadt in IE, zie je alleen een zwart vlak, maar je kan zo vaak klikken als je wilt: ik zie geen ballen... Waar kan dat aan liggen?

[wacco]

Donderwolk schreef op 20 November 2002 @ 18:51:

code:

  private class MouseClickHandler extends MouseAdapter 
  {
    public void mouseClicked( MouseEvent e )
    {
      ballen.add( new Ball(15,15,5,3,20,width,height) ); 
    }
  }

err... pleh?
* wacco heeft nog nooit van een standaard .add gehoord, laat staan dat ik hier dus ff de ballen van snap ()

Then again, ik heb ook nog nooit van een vector gehoord. Al heb ik wel een idee... ik zat namelijk te denken, arraytje, met balletjes. Maar dies op gegeven moment vol. Dus ik kwam er niet uit. Is een vector nou zegmaar een 'ongelimiteerde' array?

offtopic:
ik gá het nog wel eens snappen

[Donderwolk]

De beste beschrijving die ik voor een vector kan bedenken is: een dynamische array.
De vector groeit automatisch mee als je er objecten in stopt of uit haalt. Dit in tegenstelling tot een array waarbij je van te voren op moet geven hoe groot die moet zijn.

[Alarmnummer]

almightyarjen schreef op 20 November 2002 @ 21:56:
* Alarmnummer vindt Java maar een schijttaal, maar wil er toch iets meer van weten... Thanx voor de hulp anyways

Als ik eerlijk ben zou ik afgezien van c# je geen betere taal kunnen geven als het om oo gaat. Met java is dus niets mis. Het enigste wat er mis is, is denk ik iets bij jou: onwilligheid, kortzichtigheid. Je moet er gewoon aan wennen en dan zul je zien dat java erg ellegant isl

Ik vond java in het begin ook een kuttaal (daarvoor veel c en pascal geprogged), maar java later ben ik pas gaan inzien dat java een zeer mooie taal is.

[.oisyn]

almightyarjen schreef op 20 november 2002 @ 21:56:
* .oisyn vindt Java maar een schijttaal, maar wil er toch iets meer van weten... Thanx voor de hulp anyways

waarom? omdat de indexen 0-based zijn? Het is juist handiger, in het echte leven ook, hoewel ik nu even snel geen argumenten kan bedenken waarom (ja, ik heb er een keer serieus over na zitten denken, en toen kwam ik tot de conclusie dat 0-based logischer was dan 1-based. Ik heb trouwens ook in VB en pascal geprogrammeerd, dus ik ben iig niet bevooroordeeld )

.edit: ah, er komt alweer wat naar boven borrelen
De tijd bijvoorbeeld, een minuut loopt van 0 tot 59 seconde, niet van 1 tot 60. Zou ook niet logisch zijn, want dan net voordat de volgende minuut ingaat zouden er 60.999999 seconden voorbij gegaan zijn... klopt dus niet

Het talsysteem trouwens ook, de eenheden gaan van 0 naar 9, niet van 1 naar... ja, en toen had ik een symbool nodig gelijk aan 10 maar niet 10 zelf

0 is gewoon het begin, en het maximale is altijd kleiner dan het aantal

[wacco]

Hmm... dat met die vectoren is dan wel ff VERDOMD HANDIG.
Maarreh, kent c het ook? En hoe wordt het geregeld? Ikzelf doe nog wel eens wat aan assembly, en een array daar in programmeren zie ik nog wel gebeuren. Maar een vector... argh. Hoe moet je daar geheugen voor reserveren?
* wacco bedenkt nu terplekke een trucje, maar DAMN dat gaat een geheugen vreten
(los adres achter laatste waarde, en op dat adres gaat het weer verder: kan je later spul er gewoon bijplakken... maar afgezien van ruimte-innemend is het ook niet echt snel) (lol, kan je wel je geheugen defragmenteren )

[ Voor 0% gewijzigd door wacco op 21-11-2002 11:21 . Reden: typo ]

[almightyarjen]

Ennuh, als ik nou elke afzonderlijke bal een random kleur wil toekennen? Dan moet ik dus bij het begin van elke thread de kleur "c" (in dit geval) veranderen... Het enige wat mij lukt is de kleur van alle ballen veranderen bij een muisklik, of dat alle ballen van kleur veranderen bij elke repaint()... code voor het laatste geval:

code:

import java.awt.*;
import java.awt.event.*;
import java.applet.*;
import java.util.*;

public class Bouncy extends Applet implements Runnable
{ 
  Vector ballen = new Vector();
  int width = 0;
  int height = 0;
  int a=0,b=0,d=0;
  Color c;
  
  public void init() 
  {
    setBackground(Color.black);
    width=Integer.parseInt(getParameter("WIDTH"));
    height=Integer.parseInt(getParameter("HEIGHT"));
    addMouseListener( new MouseClickHandler() );
    (new Thread(Bouncy.this)).start();
  }

  public void run() 
  {
    while (true) 
    {
      try 
      {
        Thread.currentThread().sleep(50);
      }
      catch (InterruptedException e) {};
      repaint();
    }
  }

  public void paint(Graphics g) 
  {
    for ( int i=0; i<ballen.size(); i++ ){
      Ball tempBal = (Ball) ballen.elementAt(i);
      tempBal.moveBall();
      tempBal.drawBall( g );
    }
  }

  private class MouseClickHandler extends MouseAdapter 
  {
    public void mouseClicked( MouseEvent e )
    {
      ballen.add( new Ball(15,15,5,3,20,width,height) );
    }
  }
  public class Ball{
    int x=0,y=0,dx=0,dy=0,diam=0,sizex=0,sizey=0;

    public Ball(int x, int y, int dx, int dy, int diam, int sizex, int sizey){
      this.x = x;
      this.y = y;
      this.dx = dx;
      this.dy = dy;
      this.diam = diam;
      this.sizex = sizex;
      this.sizey = sizey; 
    }

    public void moveBall(){
a=(int)(Math.random()*256);
b=(int)(Math.random()*256);
d=(int)(Math.random()*256); 
c = new Color(a,b,d); 
      x+=dx; y+=dy;
      if ((x<=0)||(x+dx+diam>=sizex)) dx=-dx;
      if ((y<=0)||(y+dy+diam>=sizey)) dy=-dy;
    }

    public void drawBall( Graphics g ){
      g.setColor(c);
      //g.setColor(Color.white);
      g.fillArc(x,y,diam,diam,0,360);
    }
  }
}

Dus: hoe verander ik de kleur van elke afzonderlijke bal?

[wacco]

class bal misschien een extra var geven? En die dan ook doorgeven naar je Ball, en in drawBall misschien die var dan weer opvragen?

...duud

[almightyarjen]

wacco schreef op 22 November 2002 @ 00:11:
class bal misschien een extra var geven? En die dan ook doorgeven naar je Ball, en in drawBall misschien die var dan weer opvragen?

...duud

Nope, heb ik al geprobeerd... Dan krijg je een discobaleffect: elke bal verandert random van kleur...

[bazzs2001]

Color c zit in de klasse Bouncy en moet in de klasse Ball zitten, nu verander je inderdaad de kleur van alle ballen.

[Donderwolk]

Gewoon de klasse Bal inderdaad uitbreiden met een Color.

Zoiets krijg je dan:

Java:

public class Ball{
    int x=0,y=0,dx=0,dy=0,diam=0,sizex=0,sizey=0;
    Color c = Color.white;

    public Ball(int x, int y, int dx, int dy, int diam, int sizex, int sizey, Color c){
      this.x = x;
      this.y = y;
      this.dx = dx;
      this.dy = dy;
      this.diam = diam;
      this.sizex = sizex;
      this.sizey = sizey;          
      this.c = c;
    }

    public void moveBall(){
      x+=dx; y+=dy;
      if ((x<=0)||(x+dx+diam>=sizex)) dx=-dx;
      if ((y<=0)||(y+dy+diam>=sizey)) dy=-dy;
    }

    public void drawBall( Graphics g ){
      g.setColor(c);
      g.fillArc(x,y,diam,diam,0,360);
    }
  }

Wat je in je stukje code deed is natuurlijk fout en veroorzaakt inderdaad een discobal effect.

Java:

public void moveBall(){
a=(int)(Math.random()*256);
b=(int)(Math.random()*256);
d=(int)(Math.random()*256); 
c = new Color(a,b,d); 
      x+=dx; y+=dy;
      if ((x<=0)||(x+dx+diam>=sizex)) dx=-dx;
      if ((y<=0)||(y+dy+diam>=sizey)) dy=-dy;
    }

Dit komt omdat elke keer deze methode van de klasse bal wordt aangeroepen hierdoor wordt elke keer een nieuwe kleur aangemaakt en de Bal krijgt dus deze nieuwe kleur. Hierdoor krijg je dus je discobal effect.

[ Voor 30% gewijzigd door Donderwolk op 22-11-2002 11:20 ]

[wacco]

Zei ik toch...
...ben alleen te lui om voorbeeld code te tikken

[almightyarjen]

Sorry hoor, maar ik krijg het toch echt niet voor elkaar! Ze knipperen constant, of bij een muisklik. Het voorbeeld wat donderwolk hierboven heeft gegeven zet de kleur ook alleen op wit. Hoe krijg ik nou die random kleur? Ik weet het echt niet meer, heb zo'n beetje elke mogelijkheid geprobeerd

[ACM]

almightyarjen schreef op 24 november 2002 @ 22:17:
Sorry hoor, maar ik krijg het toch echt niet voor elkaar! Ze knipperen constant, of bij een muisklik. Het voorbeeld wat donderwolk hierboven heeft gegeven zet de kleur ook alleen op wit. Hoe krijg ik nou die random kleur? Ik weet het echt niet meer, heb zo'n beetje elke mogelijkheid geprobeerd

Je wilt ze random (in het begin) maar verder een vaste kleur geven?

Dat staat toch precies in Donderwolk's voorbeeld?
Gewoon de random kleur meegeven bij de initialisatie van de Ball en de drawBall regelt dan dat ie de goede kleur krijgt.
Als je dat niet bij de constructie van de Ball wilt meegeven moet je natuurlijk de random-kleur-generator apart in de constructor doen, zodat het buiten de aanroepende methode gebeurt.

Wat bedoel je met knipperen trouwens? Dat het beeld knippert bij elke redraw of dat alle ballen verschillende kleuren krijgen

[Donderwolk]

zo moeilijk is het toch niet meer? Bij het aanmaken van een bal moet je de random kleur zelf bij het aanmaken van de bal als parameter meegeven.

dus:
[voorkauw_mode]

Java:

  private class MouseClickHandler extends MouseAdapter 
  {
    public void mouseClicked( MouseEvent e )
    {
      int r = (int)(Math.random()*256);
      int g = (int)(Math.random()*256); 
      int b = (int)(Math.random()*256); 
      Color balkleur = new Color(r,g,b);
 
      ballen.add( new Ball(15,15,5,3,20,width,height,balKleur) );
    }
  }

[/voorkauw_mode]

[Donderwolk]

Ik raad je aan je nog eens wat te verdiepen in het OOP principe.
Lees dit bijvoorbeeld eens door:
http://java.sun.com/docs/books/tutorial/java/index.html