Sprites, og å la komponenter tegne seg selv

[Gjest Slettet+1374861]

Har selv ikke drevet spesielt mye med GUI, men har en generell ide om hvordan det gjøres. Jeg har jo da en stund hatt lyst til å lage enkle spill ved hjelp av Java og eksempelvis Swing. Forøvrig så ønsker jeg ikke å hoppe ut i det før jeg har kartlagt litt bedre hvordan jeg bør gå frem for å godt håndtere Sprites, og hvordan jeg kan sette opp komponenter til å tegne seg selv på en god måte.

 

Prøvde en stund å Google sprites, men fant da ofte overkompliserte eksempler som var implementert i ferdige spill, når jeg bare ønsker å ha ett utgangspunkt med det aller mest nødvendige.

 

Jeg er selv mest vandt til å bare ha en overflate (typisk JPanel, evt en extension av det) og da adde komponenter til denne overflaten, men er usikker på hvordan dette skal håndteres når komponenter senere skal ha realtime movement, oppstå og forsvinne fortløpende, og komme i form av ulike former og ImageIcon. Det blir dumt å la overflaten selv håndtere all tegning av disse innad i sine ulike tegne-metoder (paint).

 

Noen som kan komme med noen grunnleggende tips her? Hvordan bør jeg sette opp en generell Sprite klasse, og bruke den i sammenheng med oppførsel til ett objekt på en overflate?

[aC]

Har selv ikke drevet spesielt mye med GUI, men har en generell ide om hvordan det gjøres. Jeg har jo da en stund hatt lyst til å lage enkle spill ved hjelp av Java og eksempelvis Swing. Forøvrig så ønsker jeg ikke å hoppe ut i det før jeg har kartlagt litt bedre hvordan jeg bør gå frem for å godt håndtere Sprites, og hvordan jeg kan sette opp komponenter til å tegne seg selv på en god måte.

 

Prøvde en stund å Google sprites, men fant da ofte overkompliserte eksempler som var implementert i ferdige spill, når jeg bare ønsker å ha ett utgangspunkt med det aller mest nødvendige.

 

Jeg er selv mest vandt til å bare ha en overflate (typisk JPanel, evt en extension av det) og da adde komponenter til denne overflaten, men er usikker på hvordan dette skal håndteres når komponenter senere skal ha realtime movement, oppstå og forsvinne fortløpende, og komme i form av ulike former og ImageIcon. Det blir dumt å la overflaten selv håndtere all tegning av disse innad i sine ulike tegne-metoder (paint).

 

Noen som kan komme med noen grunnleggende tips her? Hvordan bør jeg sette opp en generell Sprite klasse, og bruke den i sammenheng med oppførsel til ett objekt på en overflate?

 

 

Har selv hatt lyst til det samme over lengre tid, og brukte endel tid på kartlegge fremgangsmåter.

Det beste jeg kom frem til var bruk av 3.parts spill-biblotek f.eks http://slick.cokeandcode.com/ de har etter hva jeg husker en grei wiki med noen eksempler pluss full api dokumentasjon. Det finnes også flere andre 3.parts bibloteker som er verdt å nevne, men når du nevner sprites regner jeg med at det er snakk om 2d og ikke noe full 3d med f.eks opengl.

 

Dette var kanskje ikke helt fullverdig svar og det finnes flere andre på java forumet som har laget noen spill som sikkert kan poste mer, men dette er i allefall en pekepinn over hvor det er verdt å starte å lese.

 

Mvh Axel

[Gjest Slettet+1374861]

Takker takker! Får se litt på det! Synes kanskje det også egentlig virket litt overkill, men får studere litt mer. Ønsker jo i utgangspunktet å begynne veldig enkelt, men samtidig med realtime bevegelse på mange elementer samtidig. Får se hva jeg finner ut.

[Frank2004]

Anbefaler deg å lese gjennom denne: http://java.sun.com/docs/books/tutorial/ex...reen/index.html

 

Teksten tar for seg en del konsepter du absolutt bør ha satt deg inn i for å jobbe med 'spillgrafikk', enten det er snakk om full screen eller rendring til et vindu.

[Unlimited LTD]

Leser Killer Game Programming in Java for tiden, og måten de løste det på var helt grei.

Eksempel er et spill der du skal trykke på hodet til en mark. Treffer du ikke lages en blokk, som maken må gå rundt.

 

Ved å bruke dobbeltbuffring, og så bruke i tegnemetoden:

Graphics dbg = dbImage.getGraphics();
fred.draw(dbg);
obstacles.draw();

 

Der mark er en instans av en egen klasse, Worm, og obstacles er en instans av Obstacles.

Begge klassene inneholder draw(Graphics dbg) metoder, og får grafikkobjektet til dobbeltbuffrings Image, og tegner på det med vanlige dbg.fillRect(x,y,w,h).

[zulo]

Begynn med å tegne opp et Image i spillvinduet ditt for å teste, når du har gjort dette kan du lage en Sprite klasse. Hvis du tenker deg at en Sprite egentlig er bare et Image med tilleggsinformasjon som x og y posisjoner finner du sikkert ut hvordan det kan lages.

 

En enkel klasse Sprite kan f.eks inneholde et Static Image objekt og 2 variabler for x og y posisjon samt metoder for å sette og lese av x og y posisjon. Også en draw(Graphics g) metode da slik at den kan tegne seg opp.

 

Opprett alle Image objekter på ett sted i hovedprogrammet og send de inn til Sprite objektene. Husk å gjøre Image objektene static.

 

Image bilde;

 

Sprite spillfigur = new Sprite(bilde);

 

Sånn, da har du en sprite som du kan tegne opp ved å kalle på draw metoden til sprite objektet. Du kan bruke et JPanel som tegneflate f.eks og sette opp en animasjonsloop der du tegner alle objektene om igjen hele tiden så fort som mulig.

 

I animasjonsloopen trenger du bare gjøre 3 ting egentlig.

 

1. Kall på en metode der du har all kode som har med logikk å gjøre, f.eks oppdater posisjonene til sprite objektene.

 

2. Blank ut hele skjermen/tegneflaten

 

3. Tegn opp alle sprite objektene på nytt

 

En slik sprite klasse er vel litt kjedelig når den bare har 1 bilde. Jeg pleier å la sprite klassen ha en Image array med flere bilder, da må du også legge til kode i sprite klassen for å veksle mellom bildene, enten ved å ha en oppdater() metode eller at du gjør det i draw() metoden hver gang den kalles.

[Gjest Slettet+1374861]

Sweet innlegg zulo. Ett par ting...

 

Opprett alle Image objekter på ett sted i hovedprogrammet og send de inn til Sprite objektene. Husk å gjøre Image objektene static.

 

Hvorfor det voldsomme fokuset på å ha statiske Image objekter i posten din (har ikke fått testet det du sier i praksis enda)?

Det første du nevner i sitatet her fikk jeg ett inntrykk av en annen plass at var viktig iforhold til at bildene ikke skulle lagge. Altså å opprette en instans av hvert bilde, og ha referanser til de i ett slags bildebibliotek. Fikk inntrykk av at hvis du hadde nok instanser av ting, og skulle fylle ut bildene samtidig som du laget nye instanser så kunne det hende at bilder, muligens animasjoner, kunne begynne å lagge. Kan dette stemme?

Endret 17. februar 2008 av Slettet+1374861

[zulo]

Dette med statiske Image objekter er for å spare på minnebruken. Når et objekt f.eks en Sprite inneholder et Image vil alle dataene for bildet ligge i minnet. Hvis du da har et par hundre Sprite objekter av samme type som bruker samme bilde og bildet ikke er statisk vil det være 100 potensielt helt like bilder i minnet samtidig.

 

For å si det på en annen måte, et static Image objekt vil være låst til 1 forekomst for hele programmet eller faktisk alle programmer av samme type, du kan starte spillet 3 ganger og bildedataene blir bare lastet 1 gang.