De Devschuur Coffee Corner - Iteratie 4

[PrisonerOfPain]

Een andere, maar compleet geldige reden, is dat op consoles JITs niet toegestaan zijn, om de simpele reden dat ze het niet toestaan dat userland applicaties pages als executable markeren.

gerrymeistah schreef op dinsdag 17 december 2013 @ 14:36:
Wat mij stoort, en waar ik dus ook naar refereerde, is dat ik, zelfs al praat ik met een software developer, iets te vaak(lees: bijna altijd) moet uitleggen dat game development ook in Java kan, en dat Java helemaal niet zo langzaam is als men vaak denkt. En dat men het mij pas gelooft als ik er benchmarks bij pak. Na een tijdje frustreert dat een beetje.

Je kunt ze dan prima naar Minecraft wijzen.

[Merethil]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 14:42:
Een andere, maar compleet geldige reden, is dat op consoles JITs niet toegestaan zijn, om de simpele reden dat ze het niet toestaan dat userland applicaties pages als executable markeren.


[...]


Je kunt ze dan prima naar Minecraft wijzen.

Maar juist Minecraft is een goed voorbeeld van een slecht presterend spel

[ZaZ]

Maar dat komt door de verbluffende graphics waar de computers van vandaag de dag gewoon nog niet klaar voor zijn

[.oisyn]

Inderdaad, Minecraft vind ik nou niet per se een goede showcase. Maar dat is dan vooral omdat Notch gewoon niet zo'n kei is in het schrijven van goede en efficiente code, dat kun je Java nauwelijks aanrekenen

[ Voor 10% gewijzigd door .oisyn op 17-12-2013 14:59 ]

[Hydra]

Merethil schreef op dinsdag 17 december 2013 @ 14:57:
Maar juist Minecraft is een goed voorbeeld van een slecht presterend spel

Mwoa. Het is niet te vergelijken met een gemiddelde 3D shooter. Niet dat Notch nu een "top notch" (huhu) developer is, maar het probleem van al die miljoenen blokken in een volledig dynamische wereld is niet triviaal. Daar liep ik ook tegenaan met een MC viewer in Java die ik een paar jaar terug gemaakt had.

[Merethil]

Volgens mij lag het ook aan de aanpak van hoe hij de blocks in een level opbouwde. Zes plaatjes die hij in realtime aan elkaar plakte ofzo?

[ Voor 4% gewijzigd door Merethil op 17-12-2013 14:59 ]

[Korben]

gerrymeistah schreef op dinsdag 17 december 2013 @ 14:36:
[...]
Wat mij stoort, en waar ik dus ook naar refereerde, is dat ik, zelfs al praat ik met een software developer, iets te vaak(lees: bijna altijd) moet uitleggen dat game development ook in Java kan, en dat Java helemaal niet zo langzaam is als men vaak denkt. En dat men het mij pas gelooft als ik er benchmarks bij pak. Na een tijdje frustreert dat een beetje.

Een feature als vector math valt niet echt te benchmarken tegen Java, dus dat doen ze dan maar niet. Dan hou je dus de features over waar weinig echt voordeel uit te behalen in game development, zoals string operations.

Ik kan aan de andere kant ook prima benchmarks tevoorschijn toveren waarin Java absoluut niet rooskleurig uit komt, op een heleboel vlakken.

De reden dat game developers C++ blijven gebruiken, is waarschijnlijk puur economisch: het levert de beste balans op tussen flexibiliteit, performance en implementatie-snelheid, en er is een enorm eco-systeem aan bruikbare componenten en tooling. Java en C# hebben simpelweg niet dezelfde kwaliteiten (die voor game developers van belang zijn).

Merethil schreef op dinsdag 17 december 2013 @ 14:57:
[...]
Maar juist Minecraft is een goed voorbeeld van een slecht presterend spel

[Hydra]

Merethil schreef op dinsdag 17 december 2013 @ 14:59:
Volgens mij lag het ook aan de aanpak van hoe hij de blocks in een level opbouwde. Zes plaatjes die hij aan elkaar plakte ofzo?

De engine zit echt wel slimmer in elkaar dan simpelweg 12 triangles voor elke cubuszijde tekenen.

Korben schreef op dinsdag 17 december 2013 @ 14:59:
Java en C# hebben simpelweg niet dezelfde kwaliteiten (die voor game developers van belang zijn).

Dat is een veel te simplistische conclusie, vooral als je kijkt naar al de indie developers die wel in Java developen.

[ Voor 32% gewijzigd door Hydra op 17-12-2013 15:03 ]

[Merethil]

Korben schreef op dinsdag 17 december 2013 @ 14:59:
[...]

Een feature als vector math valt niet echt te benchmarken tegen Java, dus dat doen ze dan maar niet. Dan hou je dus de features over waar weinig echt voordeel uit te behalen in game development, zoals string operations.

[...]

[afbeelding]

Heuy heuy heuy, sarcasme ken ik wel hoor! Ik heb alleen niet altijd zin om het te interpreteren

Hydra schreef op dinsdag 17 december 2013 @ 15:00:
[...]


De engine zit echt wel slimmer in elkaar dan simpelweg 12 triangles voor elke cubuszijde tekenen.

Ik haalde de "kennis" erover uit een interview dat ik ooit gezien had van 'm. Maar dat was toen Minecraft net in alpha 0.1 ofzo was, dus kan er weinig meer van herinneren. Het was in ieder geval in het begin ongelofelijk crappy opgezet

[Alex)]

Tegenwoordig is Minecraft wel beter opgezet dan vroeger (er werken ook andere devs aan), maar het is nog steeds een bizar zwaar spel als je kijkt naar wat je nou eigenlijk op je scherm ziet.

[Caelorum]

Tja, je moet ergens beginnen. Bedoel als je echt alles in 1 keer perfect wilt opzetten ben je een paar maanden/jaren verder voordat je überhaupt een leuk 3d dingetje hebt. Ergens moet je gewoon ook wat kort door de bocht zijn en dingen achterwege laten om resultaat te zien. Mijn 3d engine heeft bijv. momenteel nog niet eens culling of een manier om scenes naar een file weg te schrijven en laden. Dat zijn dingen die momenteel nog niet van belang zijn. Ook gebruik ik nog geen VBO indexing puur omdat het de performance nog niet erg in de weg zit en het nog wel even kan wachten
*en ja, mijn engine is qua features nog pre alpha 0.1 ^^\

[ Voor 4% gewijzigd door Caelorum op 17-12-2013 15:12 ]

[Verwijderd]

Beweren dat Java niet zwaarder is dan andere talen is echt een lachertje. Tenzij je het gaat vergelijken met PHP, heuheuheu.

[Hoogie2004]

Lol, er heeft iemand in DEV de database lopen hacken om iets te testen volgens mij...

code:

Unhandled Exception: System.Exception: No User found with the given userID OmgWtfImbaBBQ.

[Gamebuster]

.oisyn schreef op dinsdag 17 december 2013 @ 14:59:
Inderdaad, Minecraft vind ik nou niet per se een goede showcase. Maar dat is dan vooral omdat Notch gewoon niet zo'n kei is in het schrijven van goede en efficiente code, dat kun je Java nauwelijks aanrekenen

Denk je dat het veel beter had kunnen draaien in Java?

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:11:
Beweren dat Java niet zwaarder is dan andere talen is echt een lachertje. Tenzij je het gaat vergelijken met PHP, heuheuheu.

Wat is je definitie van "zwaarder"?

[Ultimation]

Kilotje of 10?

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 15:15:
[...]


Wat is je definitie van "zwaarder"?

Meer resources, meer RAM-gebruik, zwaardere processorbelasting.

Ik vind het wel vrij ironisch dat Minecraft hier vermeld wordt. Ik zou nooit gedacht hebben dat je zo'n spel kunt doen werken in Java, omdat het grafisch zo zwaar is (alles is 100% dynamisch), maar op de een of andere manier hebben Notch & co dat klaargespeeld. Ben wel vrij zeker dat Java geen geweldige keuze was voor dit spel.

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:20:
Meer resources, meer RAM-gebruik, zwaardere processorbelasting.

En waar baseer je dat op?

Ik vind het wel vrij ironisch dat Minecraft hier vermeld wordt. Ik zou nooit gedacht hebben dat je zo'n spel kunt doen werken in Java, omdat het grafisch zo zwaar is (alles is 100% dynamisch), maar op de een of andere manier hebben Notch & co dat klaargespeeld. Ben wel vrij zeker dat Java geen geweldige keuze was voor dit spel.

Euh, bewijst dit dan niet gewoon dat het wel meevalt?

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 15:23:
[...]


En waar baseer je dat op?


[...]


Euh, bewijst dit dan niet gewoon dat het wel meevalt?

1: Eigen ondervinding.

2: Het bewijst vooral dat de mensen die Notch bashen eigenlijk zelf geen idee hebben waarover ze het hebben.

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:26:
1: Eigen ondervinding.

Hoe heb je die vergelijking gedaan dan?

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 15:23:
[...]
En waar baseer je dat op?

Dit is wel heel erg ontkennend gedrag. We weten allemaal dat het niet zo belachelijk is als in 1995, maar het is gewoon zwaarder.

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 15:26:
[...]


Hoe heb je die vergelijking gedaan dan?

Bijvoorbeeld door mijn eigen C++ implementaties te vergelijken met de Java-implementaties van collega's, vooral dan qua RAM-gebruik. 15MB in C++ tegenover 200MB in Java voor een simpele chat client die websockets gebruikt, en dan komt dat niet doordat mijn collega er niets van kan.

[HMS]

Nieuwe input voor de 'Java is traag' discussie: http://lmax-exchange.github.io/disruptor/

[.oisyn]

Gamebuster schreef op dinsdag 17 december 2013 @ 15:14:
[...]

Denk je dat het veel beter had kunnen draaien in Java?

Het is een tijd geleden dat ik het gedraaid heb, maar ja ik denk dat het kan, zeker gezien volgens mij de grootste bottleneck zit in hoe hij de GPU aanspreekt.

Hydra schreef op dinsdag 17 december 2013 @ 14:59:
Mwoa. Het is niet te vergelijken met een gemiddelde 3D shooter. Niet dat Notch nu een "top notch" (huhu) developer is, maar het probleem van al die miljoenen blokken in een volledig dynamische wereld is niet triviaal. Daar liep ik ook tegenaan met een MC viewer in Java die ik een paar jaar terug gemaakt had.

Tja, mijn implementatie vond ik redelijk triviaal, en als ik me goed herinner was jij daar wel over te spreken want ik deed allerlei dingen die jij niet deed. Volgens mij is dat puur een kwestie van ervaring met de materie

[ Voor 48% gewijzigd door .oisyn op 17-12-2013 15:44 ]

[pedorus]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:28:
[...]


Dit is wel heel erg ontkennend gedrag. We weten allemaal dat het niet zo belachelijk is als in 1995, maar het is gewoon zwaarder.

Meer resources (welke dan?), geheugen en processorgebruik dan wat dan? Waarom worden programming contests hier gewonnen met java?
NMe in "Programming Contest Nieuwe Stijl: Contest 3 *uitslagen!*"
NMe in "Programming Contest Nieuwe Stijl: Contest 4 *Score-update*"

Ik zie eigenlijk zelf niet zoveel verschil in resourcesgebruik t.o.v. bijv. C#/.net.

Verwijderd schreef op dinsdag 17 december 2013 @ 15:30:
[...]

Bijvoorbeeld door mijn eigen C++ implementaties te vergelijken met de Java-implementaties van collega's, vooral dan qua RAM-gebruik. 15MB in C++ tegenover 200MB in Java voor een simpele chat client die websockets gebruikt, en dan komt dat niet doordat mijn collega er niets van kan.

15MB is nog steeds veel. Het verschil zal vooral komen door libraries, instellingen van de vm en garbage collection. Dat zijn veelal initiële kosten, dus als een programma meer geheugen nodig heeft (zoals een spel), speelt dit een stuk minder.

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:30:
Bijvoorbeeld door mijn eigen C++ implementaties te vergelijken met de Java-implementaties van collega's, vooral dan qua RAM-gebruik. 15MB in C++ tegenover 200MB in Java voor een simpele chat client die websockets gebruikt, en dan komt dat niet doordat mijn collega er niets van kan.

Ja hallo. Dat is dus precies wat er mis gaat. Je vergelijkt het geheugengebruik van een hele VM met dat van een simpele platform-specifieke binary. Ik ben vooral benieuwd naar je beweringen over de snelheid. De geheugenoverhead van een VM is voor de meeste applicaties uberhaupt niet van belang.

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:28:
Dit is wel heel erg ontkennend gedrag. We weten allemaal dat het niet zo belachelijk is als in 1995, maar het is gewoon zwaarder.

Onzin. Ik beweer nergens dat de architectuur van Java compleet anders is. Maar als je Java af gaat zeiken om het geheugengebruik van een VM ben je gewoon naar excuses aan het zoeken in plaats van, zoals het een fatsoenlijke software dev betaamt, objectieve afwegingen te maken.

pedorus schreef op dinsdag 17 december 2013 @ 15:35:
Ik zie eigenlijk zelf niet zoveel verschil in resourcesgebruik t.o.v. bijv. C#/.net.

Aangezien .Net ook een eigen VM heeft is dat nogal logisch

[ Voor 9% gewijzigd door Hydra op 17-12-2013 15:42 ]

[PrisonerOfPain]

pedorus schreef op dinsdag 17 december 2013 @ 15:35:
[...]
Meer resources (welke dan?), geheugen en processorgebruik dan wat dan?

Geheugen is een resource. Er zijn gewoon een hoop dingen die je niet kunt doen in Java, er zijn geen verschillende allocators (goh) dus je kunt minder goed gebruik maken van het feit dat een object maar een bepaalde life-time heeft, er is vziw geen geheugen aliassing mogelijk, je hebt geen SIMD support (of geem expliete support andere CPU instructies for that matter). Je hebt geen controle over geheugen alignment, en vrijwel al je objecten hebben een contante overhead vanwege boxing/unboxing/object tagging.

Waarom worden programming contests hier gewonnen met java?
NMe in "Programming Contest Nieuwe Stijl: Contest 3 *uitslagen!*"
NMe in "Programming Contest Nieuwe Stijl: Contest 4 *Score-update*"

Hoger percentage inzendingen? Verder worden die contests gebasseerd op score en niet op snelheid. Een hoop inzendingen draaien gewoon voor 15-30 minuten tot ze een resultaat hebben.

Ik zie eigenlijk zelf niet zoveel verschil in resourcesgebruik t.o.v. bijv. C#/.net.

Het ging over C++. Dat het ongeveer op een lijn ligt met .Net zal best.

[Verwijderd]

Craft is een Minecraft clone geschreven in C.

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 15:41:
Onzin. Ik beweer nergens dat de architectuur van Java compleet anders is. Maar als je Java af gaat zeiken om het geheugengebruik van een VM ben je gewoon naar excuses aan het zoeken in plaats van, zoals het een fatsoenlijke software dev betaamt, objectieve afwegingen te maken.

Ik zeik Java niet af. Ik stel dat er objectieve, meetbare verschillen zijn met C++ die er voor zorgen dat Java by design meer geheugen gebruikt.

[Hydra]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:47:
Ik zeik Java niet af. Ik stel dat er objectieve, meetbare verschillen zijn met C++ die er voor zorgen dat Java by design meer geheugen gebruikt.

En waar ontken ik dat dan?

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 15:48:
[...]


En waar ontken ik dat dan?

Oh. Het word zo'n discussie.

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 15:41:
[...]


Ja hallo. Dat is dus precies wat er mis gaat. Je vergelijkt het geheugengebruik van een hele VM met dat van een simpele platform-specifieke binary. Ik ben vooral benieuwd naar je beweringen over de snelheid. De geheugenoverhead van een VM is voor de meeste applicaties uberhaupt niet van belang.


[...]


Onzin. Ik beweer nergens dat de architectuur van Java compleet anders is. Maar als je Java af gaat zeiken om het geheugengebruik van een VM ben je gewoon naar excuses aan het zoeken in plaats van, zoals het een fatsoenlijke software dev betaamt, objectieve afwegingen te maken.


[...]


Aangezien .Net ook een eigen VM heeft is dat nogal logisch

Hoe moet ik dit precies begrijpen? Ik mag, naar jouw mening, het feit dat Java een VM gebruikt niet meetellen? Op die manier kan je inderdaad alles de hemel inprijzen.

[pedorus]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:44:
Hoger percentage inzendingen? Verder worden die contests gebasseerd op score en niet op snelheid. Een hoop inzendingen draaien gewoon voor 15-30 minuten tot ze een resultaat hebben.

Het ging over C++. Dat het ongeveer op een lijn ligt met .Net zal best.

Het ging toch over talen, dus zeg C++, C#, Python, Ruby, Javascript, enz.? Nu vergelijk je net met die ene taal (C++) die zo geoptimaliseerd is voor snelheid dat dit security- en developmentproblemen oplevert. En dan nog steeds zie je een migratie richting c#/java vanaf c++ bij zaken waar tijd erg belangrijk is, zoals HFT, ivm developmentsnelheid.

Verwijderd schreef op dinsdag 17 december 2013 @ 15:50:
[...]

Hoe moet ik dit precies begrijpen? Ik mag, naar jouw mening, het feit dat Java een VM gebruikt niet meetellen? Op die manier kan je inderdaad alles de hemel inprijzen.

Ik snap niet waarom die 200MB initiële kosten relevant is voor een spelletje op een machine met 8gb+ geheugen?

[PrisonerOfPain]

pedorus schreef op dinsdag 17 december 2013 @ 15:53:
Ik snap niet waarom die 200MB initiële kosten relevant is voor een spelletje op een machine met 8gb+ geheugen?

Die Playstation 3 die in je woonkamer staat, die heeft maar 256MB ram

[Verwijderd]

pedorus schreef op dinsdag 17 december 2013 @ 15:53:
[...]


[...]

Het ging toch over talen, dus zeg C++, C#, Python, Ruby, Javascript, enz.? Nu vergelijk je net met die ene taal (C++) die zo geoptimaliseerd is voor snelheid dat dit security- en developmentproblemen oplevert. En dan nog steeds zie je een migratie richting c#/java vanaf c++ bij zaken waar tijd erg belangrijk is, zoals HFT, ivm developmentsnelheid.

[...]

Ik snap niet waarom die 200MB initiële kosten relevant is voor een spelletje op een machine met 8gb+ geheugen?

Ik snap niet waar ik geïmpliceerd heb dat die 200MB kosten initieel waren. Weet je dat dit zo is, of veronderstel je het omdat het je mening ondersteunt en dus wel correct moet zijn?

[Merethil]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:54:
[...]


Die Playstation 3 die in je woonkamer staat, die heeft maar 256MB ram

Die Playstation 3 die in je woonkamer staat, die zal dan ook zeker geen standaard Java VM toegewezen krijgen.
Laten we wel zijn: Daar kan je voor optimaliseren en dus zal een VM daar ook voor worden geoptimaliseerd.

Die PC die in je studeerkamer/werkkamer staat, die kan best meer dan 256 MB hebben. Anders wordt Windows 7 al geen pretje

Verwijderd schreef op dinsdag 17 december 2013 @ 15:55:
[...]

Ik snap niet waar ik geïmpliceerd heb dat die 200MB kosten initieel waren. Weet je dat dit zo is, of veronderstel je het omdat het je mening ondersteunt en dus wel correct moet zijn?

Als ik een JVM start zit je tegen zo'n 200 MB aan te kijken standaard inderdaad. Onze Java instances voor onze Glassfish servers starten ook standaard met zoiets aan geheugengebruik. Lijkt me dan een vrij duidelijk startpunt.

[ Voor 33% gewijzigd door Merethil op 17-12-2013 15:57 ]

[.oisyn]

pedorus schreef op dinsdag 17 december 2013 @ 15:53:
[...]


[...]

Het ging toch over talen, dus zeg C++, C#, Python, Ruby, Javascript, enz.?

Nee, het ging over C++. Het begon met DeathRaven's opmerking dat ie niet wist welke klasse hij moest gebruiken om z'n pointers in te wrappen.

Nu vergelijk je net met die ene taal (C++) die zo geoptimaliseerd is voor snelheid dat dit security- en developmentproblemen oplevert. En dan nog steeds zie je een migratie richting c#/java vanaf c++ bij zaken waar tijd erg belangrijk is, zoals HFT, ivm developmentsnelheid.

Dat laatste betwijfel ik zeer. Hoe vaak ik wel niet wordt gecontact door recruiters in het HFT wereldje, die heel erg zitten te azen op game developers met C++ ervaring.

[Korben]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:50:
[...]

Hoe moet ik dit precies begrijpen? Ik mag, naar jouw mening, het feit dat Java een VM gebruikt niet meetellen? Op die manier kan je inderdaad alles de hemel inprijzen.

Nee, wat Hydra probeert aan te stippen is dat de JVM, en ook de CLR, standaard veel meer geheugen gebruiken dan de runtime van een C/C++-programma.

Als je in Managed C++ een vergelijkbaar programma in assembler zou schrijven (wat kan) en je zorgt dat de CLR wel gewoon geïnitialiseerd wordt, dan zal je waarschijnlijk ongeveer hetzelfde hoge geheugengebruik zien.

Daarnaast is het natuurlijk wel zo dat in een memory-managed taal het geheugengebruik inherent hoger is dan dat in een memory-unmanaged taal, vanwege object tracking. Allerlei leukje trucjes als dynamic invocation en reflection gebruiken ook allemaal extra geheugen. .NET is bijvoorbeeld niet in staat om strings als ANSI op te slaan, maar alleen als UCS-2. Hoppa, alle strings kosten twee keer zoveel geheugen als soms nodig is.

.oisyn schreef op dinsdag 17 december 2013 @ 15:56:
[...]
Dat laatste betwijfel ik zeer. Hoe vaak ik wel niet wordt gecontact door recruiters in het HFT wereldje, die heel erg zitten te azen op game developers met C++ ervaring.

Er zal daar ongetwijfeld een trade-off zijn tussen extreme high performance (jouw pakkie an) en extreem snel wijzigingen kunnen doorvoeren in algoritmes (managed talen).

[ Voor 17% gewijzigd door Korben op 17-12-2013 15:59 ]

[PrisonerOfPain]

Merethil schreef op dinsdag 17 december 2013 @ 15:56:
[...]


Die Playstation 3 die in je woonkamer staat, die zal dan ook zeker geen standaard Java VM toegewezen krijgen.
Laten we wel zijn: Daar kan je voor optimaliseren en dus zal een VM daar ook voor worden geoptimaliseerd.

Buiten het feit om dat er nooit een JIT op zo'n apparaat zal draaien vanuit een security oogpunt (heh), heeft een VM gewoon geen plek in dit soort toepassingen. Het is nu eenmaal absoluut niet praktisch als je performance enorm van de ene naar de andere plek schiet per frame (zelfs als het sneller word). Simpelweg omdat het dan minder goed meetbaar en minder herhaalbaar is.

[Verwijderd]

Korben schreef op dinsdag 17 december 2013 @ 15:57:
[...]

Nee, wat Hydra probeert aan te stippen is dat de JVM, en ook de CLR, standaard veel meer geheugen gebruiken dan de runtime van een C/C++-programma.

Als je in Managed C++ een vergelijkbaar programma in assembler zou schrijven (wat kan) en je zorgt dat de CLR wel gewoon geïnitialiseerd wordt, dan zal je waarschijnlijk ongeveer hetzelfde hoge geheugengebruik zien.

Daarnaast is het natuurlijk wel zo dat in een memory-managed taal het geheugengebruik inherent hoger is dan dat in een memory-unmanaged taal, vanwege object tracking. Allerlei leukje trucjes als dynamic invocation en reflection gebruiken ook allemaal extra geheugen. .NET is bijvoorbeeld niet in staat om strings als ANSI op te slaan, maar alleen als UCS-2. Hoppa, alle strings kosten twee keer zoveel geheugen als soms nodig is.

Daar ben ik me van bewust. Wat ik verwarrend vind is dat deze eigenschap van Java volgens hem niet als nadeel van Java gezien mag worden.

[TheNephilim]

4 uur, blikje!

Ondertussen hier even verder lezen; snap er niet veel van maar vind het toch wel interessant

[Korben]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:59:
[...]

Daar ben ik me van bewust. Wat ik verwarrend vind is dat deze eigenschap van Java volgens hem niet als nadeel van Java gezien mag worden.

Hangt geheel af van je omgeving dus. Zoals PrisonerOfPain zegt, op een PS3 is het een extreem nadeel dat al zo'n 5-7% van je geheugen (er van uit gaand dat 256 MB geheel beschikbaar is voor je eigen code) besteed wordt aan dingen waar je eigenlijk weinig aan hebt.

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:50:
Hoe moet ik dit precies begrijpen? Ik mag, naar jouw mening, het feit dat Java een VM gebruikt niet meetellen? Op die manier kan je inderdaad alles de hemel inprijzen.

Nee, maar dat het gewoon een inherente eigenschap van een VM taal is. Als je dat een nadeel vindt, prima, maar het is geen discussiepunt. Als geheugen een kritiek punt is (zoals in embedded systemen) is het hardstikke logisch om voor bijvoorbeeld C te gaan. Voor een uitgebreide desktop applicatie / game is die VM overhead verwaarloosbaar.

Waar het mij vooral op ging was je bewering over "zwaardere processorbelasting", ik ben benieuwd naar je bron hiervan.

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 15:49:
Oh. Het word zo'n discussie.

Doe niet zo kinderachtig. Jij zegt dat ik ontkennend reageer. Ik ontken vooralsnog helemaal niets, ik vraag naar zijn argumenten. Als je zonder argumenten loos dingen wil beweren is 't Fok forum meer geschikt voor je.

[ Voor 25% gewijzigd door Hydra op 17-12-2013 16:03 ]

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 16:01:
[...]


Waar het mij vooral op ging was je bewering over "zwaardere processorbelasting", ik ben benieuwd naar je bron hiervan.

Geen expliciete SIMD support (grote kans dat de impliciete SIMD support bagger is).

[Caelorum]

Ik denk dat wel allemaal (op 1 iemand na) wel weten wie deze discussie gaat winnen of niet? ^^

[Hydra]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:02:
Geen expliciete SIMD support (grote kans dat de impliciete SIMD support bagger is).

Fijn dat je het hem allemaal even voorkauwt.

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 16:04:
[...]


Fijn dat je het hem allemaal even voorkauwt.

Waarom moet hij het perse beantwoorden dan?

Verder, ondank dat je geheugen en perf af wilt doen als twee verschillende dingen:

[Korben]

Hydra schreef op dinsdag 17 december 2013 @ 16:01:
[...]
Nee, maar dat het gewoon een inherente eigenschap van een VM taal is.

Oneens. Toevallig hebben twee van de populairste VM-omgevingen (.NET en Java) nogal de neiging om eagerly allerlei services op te starten wanneer je een random programma aanslingert. Dat wil niet zeggen dat dat bij elke VM het geval is. Als je alleen geheugen managet, en code JIT'tt(t?) hoeft dat niet heel veel geheugen te vereisen.

[.oisyn]

Hydra schreef op dinsdag 17 december 2013 @ 16:04:
[...]


Fijn dat je het hem allemaal even voorkauwt.

Want je hoopte te winnen van iemand die er hopelijk minder verstand van had Ik snap deze opmerking niet helemaal eerlijk gezegd.

[HMS]

Wel erg makkelijk om een taal waarin bewuste keuzes zijn gemaakt t.o.v. portability van code over verschillende onderliggende CPU architecturen en operating systems, programmer safety door middel van GC, etc. er nu op afgerekend wordt dat er geen SIMD support is, geen custom geheugen allocators mogelijk zijn, etc.

Beetje appels met peren vergelijken .

[Verwijderd]

Hydra wil niet de waarheid zien, Hydra wil gewoon de discussie winnen.

Goed voorbeeld van hoe java de processor belast, is het feit dat het naar bytecode compileert, en dus in essentie een geïnterpreteerde taal is.

[PrisonerOfPain]

HMS schreef op dinsdag 17 december 2013 @ 16:06:
Wel erg makkelijk om een taal waarin bewuste keuzes zijn gemaakt t.o.v. portability van code over verschillende onderliggende CPU architecturen en operating systems, programmer safety door middel van GC, etc. er nu op afgerekend wordt dat er geen SIMD support is, geen custom geheugen allocators mogelijk zijn, etc.

Het is een perfomance discussie, dan winnen platform bewuste talen het nu eenmaal van platform agnostische talen. Verder zou Java prima een API voor SIMD kunnen hebben, zo'n beetje iedere moderen CPU ondersteunt het en het is perfect mogelijk om een scalar pad ter beschikking te stellen.

[pedorus]

Verwijderd schreef op dinsdag 17 december 2013 @ 15:55:
[...]

Ik snap niet waar ik geïmpliceerd heb dat die 200MB kosten initieel waren. Weet je dat dit zo is, of veronderstel je het omdat het je mening ondersteunt en dus wel correct moet zijn?

Op basis van eigen ervaring, net als de anderen. Maar als je niet aangeeft welke settings de jvm had, dan is het vrij lastig iets zinnigs hierover te zeggen. Zou prima kunnen dan je met -Xmx100M het geheugengebruik op 100MB had kunnen maximaliseren. Fact is dat de VM initieel geheugen zal innemen, de vraag is of deze resources relevant zijn voor een bepaald probleem.

.oisyn schreef op dinsdag 17 december 2013 @ 15:56:
Nee, het ging over C++. Het begon met DeathRaven's opmerking dat ie niet wist welke klasse hij moest gebruiken om z'n pointers in te wrappen.

Ik zie meervoud bij talen:

Verwijderd schreef op dinsdag 17 december 2013 @ 15:11:
Beweren dat Java niet zwaarder is dan andere talen is echt een lachertje. Tenzij je het gaat vergelijken met PHP, heuheuheu.

Dat laatste betwijfel ik zeer. Hoe vaak ik wel niet wordt gecontact door recruiters in het HFT wereldje, die heel erg zitten te azen op game developers met C++ ervaring.

Je ziet dus dat c++ een probleem oplevert met het vinden van de juiste developers. Zie naast die link over Disruptor hierboven, ook bijv. http://www.infoq.com/articles/low-latency-vp

[.oisyn]

HMS schreef op dinsdag 17 december 2013 @ 16:06:
Wel erg makkelijk om een taal waarin bewuste keuzes zijn gemaakt t.o.v. portability van code over verschillende onderliggende CPU architecturen en operating systems, programmer safety door middel van GC, etc. er nu op afgerekend wordt dat er geen SIMD support is, geen custom geheugen allocators mogelijk zijn, etc.

Volgens mij zit niemand hier Java af te rekenen. De discussie was vooral dat Java net zo snel kon zijn als C++. De door jouw genoemde argumenten geven aan dat inherent aan de keuzes van het platform het tegendeel het geval is.

Verwijderd schreef op dinsdag 17 december 2013 @ 16:07:
Goed voorbeeld van hoe java de processor belast, is het feit dat het naar bytecode compileert, en dus in essentie een geïnterpreteerde taal is.

Nonargument, bytecode kan vooraf worden gecompileerd naar native instructies en dat kan worden gecached. En met een beetje slimme JITer wordt het gecompileerd op basis van runtime karakteristieken, waardoor het meer potentie heeft dan gewoon vaste machinecode (zeker op toekomstige nog onbekende machines)

[ Voor 31% gewijzigd door .oisyn op 17-12-2013 16:11 ]

[Korben]

Verwijderd schreef op dinsdag 17 december 2013 @ 16:07:
Hydra wil niet de waarheid zien, Hydra wil gewoon de discussie winnen.

Goed voorbeeld van hoe java de processor belast, is het feit dat het naar bytecode compileert, en dus in essentie een geïnterpreteerde taal is.

Eh, Java wordt gewoon ge-JIT naar machinecode hoor. Beetje kansloze opmerking dit, anno 2013.

[Hydra]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:04:
Waarom moet hij het perse beantwoorden dan?

Omdat ik hem de vraag stel? Ik wil dat HIJ zijn argumenten staaft. Jij draagt prima argumenten aan voor een hele specifieke situatie (cutting edge games) die gewoon niet opgaan voor het gros van de games, laat staan standaard desktop applicaties. Ik geloof er dus geen hol van dat hij zelf hier goeie use-cases voor gezien heeft (ook al omdat hij uberhaupt verbaasd is dat MC in Java mogelijk is).

Verder, ondank dat je geheugen en perf af wilt doen als twee verschillende dingen:

[afbeelding]

Hou eens op me woorden in de mond te leggen?

Korben schreef op dinsdag 17 december 2013 @ 16:10:
Eh, Java wordt gewoon ge-JIT naar machinecode hoor. Beetje kansloze opmerking dit, anno 2013.

Q.e.d.

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:08:
Het is een perfomance discussie, dan winnen platform bewuste talen het nu eenmaal van platform agnostische talen. Verder zou Java prima een API voor SIMD kunnen hebben, zo'n beetje iedere moderen CPU ondersteunt het en het is perfect mogelijk om een scalar pad ter beschikking te stellen.

De taal java is niet platform-bewust, de VM is dit daarentegen wel. In situaties waar de VM hier ook goed gebruik van kan maken kan bij het JITten een voor dat platform (op veel gedetailleerder niveau dan een statische compiler dat kan) executiepad maken.

De VM is niet geoptimaliseerd voor games helaas, dus daarin zal het, in het geval van cutting edge games, gaan afleggen tegen bijvoorbeeld C++.

[ Voor 40% gewijzigd door Hydra op 17-12-2013 16:14 ]

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 16:10:
[...]


Omdat ik hem de vraag stel? Ik wil dat HIJ zijn argumenten staaft.

Prima. Maar er lopen meer mensen in dit topic rond, het is al de hele tijd een algemene discussie. Ik heb volgens mij al gepost dat het prima mogelijk is om games te maken die niet dergelijke performance requirements hebben.

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 16:10:
[...]


Omdat ik hem de vraag stel? Ik wil dat HIJ zijn argumenten staaft. Jij draagt prima argumenten aan voor een hele specifieke situatie (cutting edge games) die gewoon niet opgaan voor het gros van de games, laat staan standaard desktop applicaties. Ik geloof er dus geen hol van dat hij zelf hier goeie use-cases voor gezien heeft (ook al omdat hij uberhaupt verbaasd is dat MC in Java mogelijk is).


[...]


Hou eens op me woorden in de mond te leggen?


[...]


Q.e.d.

Zoals ik zei, Hydra wil enkel de discussie winnen, en is niet bepaald geïnteresseerd in de eventuele inzichten van mensen die eventueel dingen weten die hij niet weet. You must be great fun at parties.

[Caelorum]

Waar is die popcorn nou als je het nodig hebt?

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 16:12:
Zoals ik zei, Hydra wil enkel de discussie winnen

Nee. Ik wil als ik vermoed dat iemand onzin roept op basis van een gebrek aan kennis dit aantonen. En dat is gelukt.

[PrisonerOfPain]

Caelorum schreef op dinsdag 17 december 2013 @ 16:14:
Waar is die popcorn nou als je het nodig hebt?

Oppassen, die plaatjes zijn verboten!!

[.oisyn]

Hydra schreef op dinsdag 17 december 2013 @ 16:10:
Ik geloof er dus geen hol van dat hij zelf hier goeie use-cases voor gezien heeft (ook al omdat hij uberhaupt verbaasd is dat MC in Java mogelijk is).

Oftewel het gaat je om de man en niet om de discussie.

[TheNephilim]

Caelorum schreef op dinsdag 17 december 2013 @ 16:14:
Waar is die popcorn nou als je het nodig hebt?

Gezien je geen avatar hebt, zou ik een mooie popcorn-afbeelding zoeken en die gebruiken; als avatar!

[Verwijderd]

Hydra schreef op dinsdag 17 december 2013 @ 16:15:
[...]


Nee. Ik wil als ik vermoed dat iemand onzin roept op basis van een gebrek aan kennis dit aantonen. En dat is gelukt.

Oh, really? Dan moet ik een post van je gemist hebben.

[HMS]

Tja, als je 2 implementaties maakt: 1 in C++ en 1 in Java. Allebei theoretisch optimaal geimplementeerd in hun taal, dan verwacht ik dat de C++ implementatie sneller is. Met welke marge durf ik niet te zeggen, dat ligt aan wat de applicatie precies doet.

Bij geheugen intensievere applicaties denk ik dat het voordeel richting C++ gaat door de expliciete memory management, terwijl dat bij CPU intensieve applicaties zeker niet zo hoeft te zijn (JIT / HotSpot optimalisaties, I'm looking at you).

Verder, ach boeiend welke taal je kiest. Elke taal heeft zijn sterke en zwakke punten.

[RobIII]

Pomtiedom. Even de pan van 't vuur.

[RobIII]

En welkom terug ammelaal! Was even schrikken he?

[Caelorum]

TheNephilim schreef op dinsdag 17 december 2013 @ 16:16:
[...] Gezien je geen avatar hebt, zou ik een mooie popcorn-afbeelding zoeken en die gebruiken; als avatar!

Done!

[Korben]

RobIII schreef op dinsdag 17 december 2013 @ 16:35:
En welkom terug ammelaal! Was even schrikken he?

Ik heb gewoon 17 minuten lang moeten werken. Je hebt geen idee.

[pedorus]

Snelheid heeft meerdere factoren. Gegeven oneindige developmenttijd, is handgeoptimaliseerde assembly waarschijnlijk het snelst. Als je in java echter sneller een algoritme kan maken en in productie kan hebben, kan java daadwerkelijk sneller zijn in de praktijk. Voor veel gebieden zie je daarom dat in de praktijk een taal als java het snelst werkt. Voor veel games is het denk ik nu nog zo dat c++ het snelst is gegeven beide factoren, maar de kans is aanwezig dat dit in de toekomst ook een vm-taal zoals java of c# is. Het verschil lijkt al steeds kleiner te worden.

En de ps3 is ook al geen probleem voor minecraft: nieuws: Minecraft komt woensdag beschikbaar voor Playstation 3

Woei, de koffiemachine is weer gemaakt

[Verwijderd]

pedorus schreef op dinsdag 17 december 2013 @ 16:37:
Snelheid heeft meerdere factoren. Gegeven oneindige developmenttijd, is handgeoptimaliseerde assembly waarschijnlijk het snelst. Als je in java echter sneller een algoritme kan maken en in productie kan hebben, kan java daadwerkelijk sneller zijn in de praktijk. Voor veel gebieden zie je daarom dat in de praktijk een taal als java het snelst werkt. Voor veel games is het denk ik nu nog zo dat c++ het snelst is gegeven beide factoren, maar de kans is aanwezig dat dit in de toekomst ook een vm-taal zoals java of c# is. Het verschil lijkt al steeds kleiner te worden.

En de ps3 is ook al geen probleem voor minecraft: nieuws: Minecraft komt woensdag beschikbaar voor Playstation 3

Woei, de koffiemachine is weer gemaakt

Die discussie direct weer hervatten, is dat een strak plan?

[pedorus]

RobIII in "Feedback op moderatie binnen de Devschuur"

[RobIII]

Verwijderd schreef op dinsdag 17 december 2013 @ 16:38:
[...]

Die discussie direct weer hervatten, is dat een strak plan?

Van mij mag het. Zolang er niet op de man gespeeld wordt, niet getrolled wordt en 't gewoon een beschaafde discussie blijft (en dan mag 't best wel eens een beetje "oplopen", daar is niemand vies van hier).

[Hydra]

Verwijderd schreef op dinsdag 17 december 2013 @ 16:17:
Oh, really? Dan moet ik een post van je gemist hebben.

Gaat om je eigen post, en dan vooral dit:

Verwijderd schreef op dinsdag 17 december 2013 @ 16:07:
Goed voorbeeld van hoe java de processor belast, is het feit dat het naar bytecode compileert, en dus in essentie een geïnterpreteerde taal is.

Dat is volslagen onzin. En het is een veelvoorkomende misvatting

.oisyn schreef op dinsdag 17 december 2013 @ 16:15:
Oftewel het gaat je om de man en niet om de discussie.

Het ging me om een bewering van een specifieke persoon ja, maar niet om de persoon zelf. Even het nieuwe jochie laten weten hoe de vork in de steel zit

[ Voor 22% gewijzigd door Hydra op 17-12-2013 16:41 ]

[Verwijderd]

RobIII schreef op dinsdag 17 december 2013 @ 16:35:
En welkom terug ammelaal! Was even schrikken he?

Jeeeeeej

[Firesphere]

RobIII schreef op dinsdag 17 december 2013 @ 16:35:
En welkom terug ammelaal! Was even schrikken he?

In de tussentijd heeft iedereen hier jouw icon een keer verandert geloof ik

[Korben]

Firesphere schreef op dinsdag 17 december 2013 @ 16:41:
[...]

In de tussentijd heeft iedereen hier jouw icon een keer verandert geloof ik

Je moet toch wát als de CC dicht is.

[.oisyn]

pedorus schreef op dinsdag 17 december 2013 @ 16:37:
En de ps3 is ook al geen probleem voor minecraft: nieuws: Minecraft komt woensdag beschikbaar voor Playstation 3

Maar Java wel, die PS3 implementatie gebruikt dan ook geen Java

[TheNephilim]

Caelorum schreef op dinsdag 17 december 2013 @ 16:36:
[...]

Done!

Awsome, zo heeft iedereen altijd popcorn bij de hand mocht het nodig zijn

[PrisonerOfPain]

pedorus schreef op dinsdag 17 december 2013 @ 16:37:
En de ps3 is ook al geen probleem voor minecraft: nieuws: Minecraft komt woensdag beschikbaar voor Playstation 3

Ik ben er vrij zeker van dat dit een C++ port is. Zoals ik al een aantal keer heb gezegt, JITs zijn verboden op consoles vanwegen potentiele security problemen.

[Caelorum]

TheNephilim schreef op dinsdag 17 december 2013 @ 16:45:
[...] Awsome, zo heeft iedereen altijd popcorn bij de hand mocht het nodig zijn

Moet ik hier wel vaak genoeg blijven posten...

[Korben]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:46:
[...]


Ik ben er vrij zeker van dat dit een C++ port is. Zoals ik al een aantal keer heb gezegt, JITs zijn verboden op consoles vanwegen potentiele security problemen.

Wellicht pre-JIT'ted (NGEN'd in .NET lingo) Java?

[TJHeuvel]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:46:
[...]


Ik ben er vrij zeker van dat dit een C++ port is. Zoals ik al een aantal keer heb gezegt, JITs zijn verboden op consoles vanwegen potentiele security problemen.

C#/XNA draait toch gewoon op de xbox 360?

[PrisonerOfPain]

Korben schreef op dinsdag 17 december 2013 @ 16:48:
[...]

Wellicht pre-JIT'ted (NGEN'd in .NET lingo) Java?

Zou kunnen, maar de 360 versie draait gewoon in C++.

Bron: http://www.oxm.co.uk/4189...est-technical-challenges/

[Caelorum]

TJHeuvel schreef op dinsdag 17 december 2013 @ 16:49:
[...]
C#/XNA draait toch gewoon op de xbox 360?

Maar vast alleen als het goedgekeurd/ondertekend is door Microsoft.

[Korben]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 16:49:
[...]


Zou kunnen, maar de 360 versie draait gewoon in C++.

Bron: http://www.oxm.co.uk/4189...est-technical-challenges/

Interessant, het stuk over geheugen; heeft een console geen virtueel geheugen? Ik snap dat er meer problemen zijn dan alleen geheugen, maar ik vroeg het me net af.

[pedorus]

.oisyn schreef op dinsdag 17 december 2013 @ 16:45:
[...]

Maar Java wel, die PS3 implementatie gebruikt dan ook geen Java

Ik dacht al, hoe hebben ze dat nu voor elkaar kunnen krijgen

[PrisonerOfPain]

Caelorum schreef op dinsdag 17 december 2013 @ 16:51:
[...]

Maar vast alleen als het goedgekeurd/ondertekend is door Microsoft.

Meer info hier: http://gamedev.stackexcha...o-get-my-xna-game-on-xbox

MSDN: Deploying an Xbox 360 Game

[Douweegbertje]

Wacht maar gewoon. PHP is de toekomst, ook voor games. Zie hoe in de laatste PHP versie de GOTO command al is toegevoegd. Het is een kwestie van tijd totdat PHP alles overneemt.

[PrisonerOfPain]

Korben schreef op dinsdag 17 december 2013 @ 16:52:
[...]

Interessant, het stuk over geheugen; heeft een console geen virtueel geheugen? Ik snap dat er meer problemen zijn dan alleen geheugen, maar ik vroeg het me net af.

Jawel, en daar maken we ook gretig gebruik van door verschillende truukjes uit te voeren.

[.oisyn]

TJHeuvel schreef op dinsdag 17 december 2013 @ 16:49:
[...]

C#/XNA draait toch gewoon op de xbox 360?

Er is inderdaad een speciale door MS geleverde .Net sandbox waar je game eventueel in zou kunnen draaien ja. Native interop is dan niet mogelijk. Tevens kan een native game niet ook .Net code draaien. Heb je het over Java, dan heeft Sony sowieso geen eigen VM, en het gebruiken van een 3rd party VM is Uit Den Boze™ op beide consoles.

[jbdeiman]

douweegbertje schreef op dinsdag 17 december 2013 @ 16:54:
Wacht maar gewoon. PHP is de toekomst, ook voor games. Zie hoe in de laatste PHP versie de GOTO command al is toegevoegd. Het is een kwestie van tijd totdat PHP alles overneemt.

Ik moet bij het GOTO command altijd denken aan een spelletje die je op die manier moet besturen, tekstueel:
GOTO Museum, GOTO Zoo enz.

[BikkelZ]

Ahhh ja adventure games. Ik ben af en toe in een dood moment bezig met een simpel adventure spelletje in C64 BASIC. Ontzettend gelimiteerd maar wel leuk om te doen.

[PrisonerOfPain]

BikkelZ schreef op dinsdag 17 december 2013 @ 17:02:
Ahhh ja adventure games. Ik ben af en toe in een dood moment bezig met een simpel adventure spelletje in C64 BASIC. Ontzettend gelimiteerd maar wel leuk om te doen.

Relevant: http://blog.moertel.com/p...ame-programming-hack.html

[Douweegbertje]

niet relevant:

[BikkelZ]

PrisonerOfPain schreef op dinsdag 17 december 2013 @ 17:03:
[...]


Relevant: http://blog.moertel.com/p...ame-programming-hack.html

Gisteren toevallig gelezen, ik vind dat soort verhalen altijd geweldig. Ik hoop ooit een keer de tijd te hebben om wat simpels te doen met machinecode op een Commodore.

[F.West98]

Verwijderd schreef op dinsdag 17 december 2013 @ 01:00:
[...]


Ik wist niet dat er nog mensen meewerkten aan je app; is dat iemand van je klas?

Ja. Hij is begonnen in Flash, en daarna overgestapt naar Java. Alleen zijn code is dus niet best

Avalaxy schreef op dinsdag 17 december 2013 @ 01:32:
Zal wel zo'n leuk verplicht groepsproject zijn zoals op het HBO

Ik heb een keer alle 3 de andere mensen uit m'n groep de opdracht gegeven maar gewoon tutorials te gaan lezen en heb vervolgens alles zelf zitten coden. Een andere keer heb ik dmv. een contract 2 van de 4 mensen uit m'n groep kunnen zetten (die hadden dus een onvoldoende).

Nee. Gelukkig niet, had ik iets minder dan een jaar geleden, klaagde ik hier ook al
Dit is gewoon een hobbyproject

[Douweegbertje]

Waarom zoek je dan niet goede mensen als het voor een hobby project is? Laat ze eens met wat voorbeelden e.d. komen Het is dat ik zelf kapot druk ben, anders zou ik je wel helpen.. misschien volgend jaar?

[Hydra]

TJHeuvel schreef op dinsdag 17 december 2013 @ 16:49:
C#/XNA draait toch gewoon op de xbox 360?

XNA is alleen een beetje deprecated

[PrisonerOfPain]

Hydra schreef op dinsdag 17 december 2013 @ 17:35:
[...]


XNA is alleen een beetje deprecated

Er is altijd MonoGame op de PS Vita.