Toon posts:

[C/C++] Crossplatform 2D game programmeren

Pagina: 1
Acties:

Verwijderd

Topicstarter
He!

Aanleiding
Ik zat te denken: Er zijn tientallen 2d gamelibraries beschikbaar. Sommige ondersteunen meerdere platformen(Windows/Linux/PocketPC).

Stel dat ik een 2d spelletje heb gemaakt dat ik wil compilen op : Linux, Windows, Apple, Symbian, Palm, PocketPC.
Geen van de gamelibs ondersteund alle platformen.

Elk platform heeft wel een Gamelib die er uitspringt(boven de andere).
PocketPC => Gapidraw
PC => DirectX
Palm => ?
Linux =>Allegro (?)

Als ik voor linux een spel zou maken dan zou ik dus voor Allegro kiezen.
Het nadeel is dan dat ik het voor PocketPC opnieuw zou moeten maken(omdat allegro niet voor PocketPC beschikbaar is ofwel een slechter resultaat geeft dan Gapidraw).


Voorstel
Elk platform ondersteund standaard C
Waarom verzinnen we niet een standaard C gameFrameWork.
Deze moet het volgende hebben:
* gameloop
* blit functies (transparant etc)
* TextOut
* DoubleBuffer
* etc(de normale 2d functies)

De header files van het gameFrameWork zijn vrij beschikbaar op het internet.
Stel dat een AppleGuru het frameWork implementeerd op een Apple.
en een LinuxFreak het implementeerd mbv Allegro op Linux
en een PocketPC fanaat het implementeerd mbv Gapidraw op PocketPC
etc

Dan konden we onze 2d spellen op basis van het gameFrameWork maken op 1 platform en het compilen/draaien op alle andere platformen.

SamenGevat
Er zijn Crossplatform gamelibs. Deze ondersteunen niet alle platformen.
Er is dus nog iets nodig boven deze GameLibs.

Waarom verzinnen we niet met z'n allen een definitie die bovenop bestaande GameLibs draait? Zo kunnen we onze spellen uitbrengen op veel meer platformen dan voorheen mogelijk was. Ook kunnen we zo eenvoudig van onderliggend Gamelib wisselen (Dus bijv GDI ipv DirectX).

Afbeeldingslocatie: http://www.pocketmatrix.com/forums/files/cross.jpg
Wat denken jullie?

[ Voor 4% gewijzigd door Verwijderd op 12-08-2004 10:47 ]


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 15:49

Creepy

Tactical Espionage Splatterer

Je hebt al naar SDL gekeken?
Van de SDL website
Simple DirectMedia Layer supports Linux, Windows, BeOS, MacOS Classic, MacOS X, FreeBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. There is also code, but no official support, for Windows CE, AmigaOS, Dreamcast, Atari, NetBSD, AIX, OSF/Tru64, RISC OS, and SymbianOS.

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Verwijderd

Topicstarter
SDL heb ik inderdaad naar gekeken.
Helaas is SDL op PDA/Telefoons erg langzaam.
Dat is dan ook meteen het grote nadeel van SDL(en andere gamelibs).
Ze zijn snel en goed op het ene platform, maar draaien voor geen meter op andere platforms.


Wanneer we een standaard definitie zouden hebben die bovenop andere gamelibs zou draaien, dan kon ik voor elk platform de snelste gamelib gebruiken!(ipv dus een langzame gamelib die alle platformen ondersteund).

Het implementeren van die standaard definitie bovenop een gamelib zou velen malen makkelijker te realiseren zijn dan het zelf helemaal uitprogrammeren

[ Voor 34% gewijzigd door Verwijderd op 12-08-2004 11:39 ]


  • zeroxcool
  • Registratie: Januari 2001
  • Laatst online: 22-05 14:17
Verwijderd schreef op 12 augustus 2004 @ 11:37:
SDL heb ik inderdaad naar gekeken.
Helaas is SDL op PDA/Telefoons erg langzaam.
Dat is dan ook meteen het grote nadeel van SDL(en andere gamelibs).
Ze zijn snel en goed op het ene platform, maar draaien voor geen meter op andere platforms.
Daar heb je denk ik meteen het lastigste punt te pakken. Je zal optimalisaties voor iedere architectuur moeten maken. Bij de één meer dan bij de ander. Een hels karwei als je het mij vraagt.

zeroxcool.net - curity.eu


  • BurningSheep
  • Registratie: Januari 2000
  • Laatst online: 03-05 22:13
Is het niet handiger om dan dus SDL te verbeteren in plaats van weer helemaal overnieuw te beginnen met een nieuwe library? Pak bijvoorbeeld PocketHAL en maar een betere SDL port voor PocketPC.

Verwijderd

Topicstarter
ZeRoXcOoL schreef op 12 augustus 2004 @ 12:29:
[...]

Daar heb je denk ik meteen het lastigste punt te pakken. Je zal optimalisaties voor iedere architectuur moeten maken. Bij de één meer dan bij de ander. Een hels karwei als je het mij vraagt.
Optimalisaties? Omdat ik de gameFramework bovenop bestaande gamelibs(die dus al geoptimaliseerd zijn!) wil maken is dat niet nodig.
Voor Windows implementeer ik het gameFramework op een gamelib op basis van DirectX

Voor PocketPC bouw ik de gameFrameWork op basis van Gapidraw, de geoptimaliseerde gamelib voor PocketPC.

Voor Symbian bouw ik het GameFrameWork op basis van PocketFrog, de geoptimaliseerde gamelib voor Symbian

etc

[ Voor 3% gewijzigd door Verwijderd op 12-08-2004 12:38 ]


  • RickN
  • Registratie: December 2001
  • Laatst online: 14-06-2025
Zie je dan niet dat iets als SDL al _is_ wat jij voorstelt, en meer zelfs?

SDL is de api, en elk ondersteund platform implementeert die api. Of die implementatie volledig from the ground up is, of eenvoudigweg een wrapper om een reeds bestaande, efficiente api op dat platform is (jouw voorstel beperkt zich tot dat laatste), is een keuze die voor elk platform afzonderlijk gemaakt kan worden.

Het voorbeeld van de SDL is welliswaar nog niet zover gevordert als wat jij als eindproduct van jouw idee voor ogen hebt, maar er is iig al meer dan een mooi plaatje en een post op een forum.

[ Voor 25% gewijzigd door RickN op 12-08-2004 12:57 ]

He who knows only his own side of the case knows little of that.


Verwijderd

Het idee (en succes) achter Open Soers*, of beter gezegd vrije software, is juist dat je niet het wiel opnieuw hoeft uit te vinden elke keer als je gaat werken. Je kan aan een bestaand project dat er leuk uitziet meewerken om het te verbeteren, of als je wilt dat het andere kant op moet gaan dan neem je gewoon de source van het project mee en ga je op je eigen manier verder (al dan niet met aanhang die het met je eens is).

Als je in je eentje of met een paar man opnieuw begint is je kans van slagen veel kleiner. In dit geval is SDL al een stuk verder dan jij, dus waarom zou je je krachten niet combineren?

En, laten we wel wezen, een uniforme grafische library die op alle platforms optimaal draait is natuurlijk een heilige graal, en ik vraag me sterk af of het wel te realiseren is... je hebt natuurlijk ALTIJD beperkingen van het ene platform ten opzichte van het andere. En als je altijd maar de grootste gemene deler neemt komen je spelletjes op de sterke platforms lang niet zo goed uit de verf, en zal niemand ze willen spelen.

* Sorry, ik kan het niet laten. Uit nostalgische overwegingen spreek ik "source" nog altijd stug uit als "soers" en in het geval van Open ~ schrijf ik het ook zo ;).

  • zeroxcool
  • Registratie: Januari 2001
  • Laatst online: 22-05 14:17
Verwijderd schreef op 12 augustus 2004 @ 12:37:
[...]
Optimalisaties? Omdat ik de gameFramework bovenop bestaande gamelibs(die dus al geoptimaliseerd zijn!) wil maken is dat niet nodig.
Voor Windows implementeer ik het gameFramework op een gamelib op basis van DirectX

...
blabla
...
Dan heb ik je verkeerd begrepen...

zeroxcool.net - curity.eu


  • .oisyn
  • Registratie: September 2000
  • Laatst online: 22-05 23:07

.oisyn

Moderator Devschuur®

Demotivational Speaker

Je gaat imho ook compleet voorbij aan de redenen waarom sommige libs wat minder werken op andere platforms. Dat is gewoon omdat de opzet op zo'n manier in elkaar zit dat het gewoon niet erg lekker werkt op een bepaald platform, en dat zul je altijd houden. Direct3D was bijvoorbeeld ook altijd wat minder dan Glide voor voodoo kaarten, door de verschillende manieren waarop ze opgezet waren. De extra vertaalslag kost in sommige gevallen gewoon tijd, of de optimalisatie-strategie die je op een bepaald platform voor ogen hebt hoeft helemaal niet goed te werken op een ander platform. Je zult dus altijd houden dat je lib op bepaalde platforms wat minder presteert dan een voor dat platform native library, en dat is iets waar je je bij neer zult moeten leggen.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.


Verwijderd

Zoals onze goede moderator boven al stelt, je wilt iets wat principieel niet goed kan. Het ene platform werkt nu eenmaal anders als de andere. Zie ook bv de verschillende J2ME configuraties. Deze API's zouden het ook mogelijk moeten maken om universeel en voor veel soorten devices (2D) games te maken. Je ziet echter dat devices nogal uiteenlopen op 'simpele' zaken als resolutie, kleur-diepte, soort knoppen en natuurlijk memory en CPU power.

Overigens, wat ook nog een leuke 'library' is, die al naar heel veel platformen is geport (Amiga, Apple, PC-Windows, PC-Linux, Symbian en zelfs een digitale camera), is MAME. Dit is eigenlijk een emulator (maar strict genomen is de JVM dat ook), met heel veel 'configuraties'. De oorspronkelijke bedoeling is om bestaande games te emuleren, maar niemand verbied je natuurlijk om er nieuwe games voor te maken. De allerlichtste drivers draaien overal op, en kun je toch nog grappige 2d dingen mee doen. De iets zwaardere drivers (bv System16 of NeoGeo) draaien al vanaf +- G3 266 en kun je echt enorm veel 2D effecten mee gebruiken.

Net zoals Java heeft dit tevens het voordeel dat je ook maar 1 keer hoeft te compileren.

Verwijderd

MAME is toch een emulator van arcade-kasten?

Verwijderd

Verwijderd schreef op 12 augustus 2004 @ 22:42:
MAME is toch een emulator van arcade-kasten?
Dat klopt ja, maar om dat te realiseren is er een enorme library van cross-platform code geschreven voor het afhandelen van graphics en emulatie taken. Mame is niet echt de snelste implementatie, maar het schijnt redelijk makkelijk te porten te zijn naar nieuwe architecturen.

Als je een app voor Mame schrijft kun je je dus richten op een van de vele drivers. Jouw applicatie zal dan draaien op alle platformen waar Mame draait en die driver gesupport wordt. Dat zijn, zeker voor de lichtste drivers, een behoorlijk aantal platformen.

En natuurlijk gaat het niet zo heel makkelijk. Om de binary te maken moet je eigenlijk over de development kit met bijbehorende cross-compiler beschikken voor de driver waarop je je richt.
Pagina: 1