Archief - [ALG] Welke taal?

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

Vich

Legacy Member
killgore zei:
Veel (niet alle) console-games die naar pc geport worden draaien op emulators, kan je moeilijk cross-platform noemen.
Het lijkt me sterk dan men PS2/PSP/XBox360/XBox games gaat emuleren op de PC(om die dus zo commerciëel te kunnen verkopen voor dat platform). Zo'n emulator schrijven is vast meer werk dan je code porten?
Daarbij komt nog eens dat je een enorm prestatieverlies hebt.

Tyfius zei:
Vele van die geporte apps maken ook gebruik van een andere grafische toolkit da n die van windows. Wat het porten al een heel pak vereenvoudigd. Daarenboven zijn het dan mensen zoals u en ik die de intentie hebben om dit te doen, en onze tijd daar in zullen steken, waar het bij niet opensource/gratise applicaties die voor windows zijn ontwikkeld al een heel pak moeilijker wordt.
áls een programma goed is geschreven, dan kan dat met élke gui/grafische toolkit werken. En bijgevolg kan men het makkelijk porten.

killgore

Legacy Member
Vich zei:
Het lijkt me sterk dan men PS2/PSP/XBox360/XBox games gaat emuleren op de PC(om die dus zo commerciëel te kunnen verkopen voor dat platform). Zo'n emulator schrijven is vast meer werk dan je code porten?
Het valt te zien wat ze juist bedoelden met emulators eh. Ik meende dat dit niet de emulators waren zoals fanbases van bv. gameboy uitbrengen :p, maar eerder libs die gelinkt worden en de werking van de console op bepaalde delen emuleren. Maar ik heb nooit voor console gecode dus das beke int donker tasten voor mij, kheb alleszins nooit games gezien waar duidelijk emulator dll's of exes bijzaten, maar vaak genoeg van nieuwe releases (wel al 2-3 jaar geleden, nu volg ik dat niet meer zo) gelezen dat deze via emulators werkten. Wat je daaronder moet verstaan is natuurlijk onduidelijk.

Daarbij komt nog eens dat je een enorm prestatieverlies hebt.
Dit is zeer relatief denk ik (zie uitleg op vorige quote) + als een console al bv. 2 jaar oud is wordt een pc-port daarvan vrij vlot hoor, tenzij je natuurlijk eist dat het op stone-age pc's draait :). Het is al jarenlang niet meer zo dat de console de pc ver voorop zit.

kwitters

Legacy Member
.Acku. zei:
Bij talen met ene runtime environment heb je toch gewoon minder problemen om te ontwikkelen voor meedere platforms. Er worden niets eens echte testen voorzien voor de 'ports' aangezien er geen echte 'ports' zijn. Gewoon een deploy op een ander systeem.

Theoretisch gezien is dit allemaal mooi, maar spijtig genoeg is het in de praktijk soms anders. Wij ontwikkelen hier ook java j2me games, en die moeten wel degelijk "geport" worden naar elk individueel toestel, en dus ook getest. En met porten bedoel ik niet enkel het verschil van de schermresoluties oplossen, maar ook effectieve function calls veranderen. De oorzaak hiervan is buggy implementaties van de verschillende runtime environments op de toestellen/emulators (die door Sun java certified zijn).

We hadden hier ooit een stagair die ook van de veronderstelling uitging dat java platform onafhankelijk was: "Als die code op het ene toestel werkt moet dat toch ook evengoed op een ander toestel werken, java is toch platform onafhankelijk", waarop ik zei: "zou moeten ja, maar het is niet zo, welcome to the real world" ;)

.Acku.

Legacy Member
J2ME is toch een beetje een klasse apart, de hardware van GSM's is gewoon erg uiteenlopend en het is ook erg moeilijk daar EEN enkele goede standaard voor te voorzien. Bij PC's ligt dat helemaal anders.

.Acku.

Legacy Member
Momenteel help ik mee in een team van +-10 ontwikkelaars (architecten, managers en ingenieurs buiten beschouwing gelaten dus) aan een applicatie die geheel de SAP (Service Access Provider), ISP-kant en Terminal kant verzorgt voor satteliet-communicatie. Dat is dus o.a van een Desktop GUI waar een medewerker een nieuwe terminal in activeert tot de entries in de Cisci routing tabellen toe, naar voorzieningen zoals Shaping, VoIP, Peak rate limiting, caching, QoS, modulatie etc.
Dat is een serieuze bedrijfskritische applicatie. En dat draait probleemloos tegelijk op Linux als Windows, het dev-platform is volledig vrij. Ook al wordt er met serieus wat hardware gepraat, de code is 95% Java (enkel device drivers niet, die zijn afgescheiden via remoting en stubs).

killgore

Legacy Member
Als da reply was op mijn (gedelete) post: moogde gerust negeren, was niet rechtstreeks als aanval op java bedoelt ;), beetje verkeerd overgekomen.

Ma wel schoon vb :niceone:

Cheops

Legacy Member
Ik passeer maar eens maar vond toch volgend statement schokkend ;-)

Originally Posted by The Crazy Frog
Kvind het een beetje raar dat ze niet gewoon de gebruikte libs in de exe steken, zoals bij C (feel free to explain why).

uhu ...

Vich

Legacy Member
Cheops zei:
Ik passeer maar eens maar vond toch volgend statement schokkend ;-)

Originally Posted by The Crazy Frog
Kvind het een beetje raar dat ze niet gewoon de gebruikte libs in de exe steken, zoals bij C (feel free to explain why).

uhu ...

*negeert dat statement gewoon verder* :music:

[edit] Alhoewel, ik ga maar es aardig doen:
- libs statisch linken in een exe maakt een executable groter. Als je meerdere executables hebt op je PC die dezelfde libs gebruiken, dan kan je beter dynamisch linken(dll), zodat er geen dubbele code wordt opgeslagen. Zo worden je executables een pak kleiner.
- libs kan je statisch OF dynamisch linken in C én C++ (dus respectievelijk erinsteken of apart erbij leveren)
- bij .NET gaat het 'm niet enkel om libs, maar ook de hele runtime environment, die de bytecode kan interpreteren van de executable, omdat de executable geen machinecode is heeft de PC dat platform nodig.

killgore

Legacy Member
Vich zei:
- libs kan je statisch OF dynamisch linken in C én C++ (dus respectievelijk erinsteken of apart erbij leveren)
en véél libs ga je dynamisch linken.

Neem nu opengl of directx. Zou maar pain in the ass zijn moest da in elk game zitten ingecompiled eh :s.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan