Garage Games maakt Torque 3D-engine opensource
Garage Games heeft de repositories openbaar gemaakt met de broncode van hun Torque 3D-engine. De code staat op GitHub en bevat de laatste versie van de engine. De ontwikkelaar levert er bovendien vier gametemplates bij.
Garage Games maakte eerder deze maand al bekend dat ze de broncode van hun Torque 3D-engine onder de opensource-licentie beschikbaar zouden stellen. Dat is inmiddels gebeurd. De ontwikkelaar heeft twee repository's op GitHub geplaatst, een repository met de broncode van de engine en een tweede met documentatie. Het gebruik van de code valt onder de MIT License, die gebruikers veel meer vrijheid geeft dan de veelvoorkomende GNU General Public License. Om gebruikers op weg te helpen, levert Garage Games vier templates mee waarop nieuwe games gebaseerd kunnen worden.
De repository bevat de laatste versie van de engine. Om de download beperkt te houden heeft Garage Games wat textures en losse modules weggelaten die wel opgenomen waren in de commerciële versie van de engine. Welke dat zijn, is niet bekend. De ontwikkelaar belooft zelfs de kosten te vergoeden van partijen die kort voor het vrijgeven van de engine een licentie afgesloten hebben om de engine te mogen gebruiken. De Torque-engine werd gemaakt voor shooter Tribes 2 uit 2001 en werd daarna gebruikt voor minder bekende games als Ultimate Duck Hunting, ThinkTanks, Penny Arcade Adventures, SPAZ en Frozen Synapse.
Reacties (32)
Zelfs MS-RL license geeft meer vrijheid dan een OSS license zoals de GNU.Het gebruik van de code valt onder de MIT License, die gebruikers veel meer vrijheid geeft dan de veelvoorkomende GNU General Public License
Van de andere kant, bij GNU GPL weet je 99,9% zeker dat alle 'officiele' contributies worden teruggekoppeld. Je applicatie 'groeit'.
Bij MIT / BSD 3-Clause / X11 licencies kan een bedrijfje doodleuk je code pakken, alle algoritmes optimaliseren, 100 features toevoegen en de nieuwe code niet 'teruggeven'.
Persoonlijk zou ik niet voor de MS-RL kiezen omdat het nagenoeg geen verschil in resultaat heeft als de MIT / BSD 3-Clause / X11.
Je hebt ook eenmaal een groep mensen die denigrerend doen over dingen die een referentie naar Microsoft hebben, dus om die groep te bereiken ligt het voor de hand om een licentie die niet uit huize Redmond komt.
Overigs pas ik dezelfde mening toe over de licentie(s) uit Cupertino en MPL (en zijn afgeleiden).
Bij MIT / BSD 3-Clause / X11 licencies kan een bedrijfje doodleuk je code pakken, alle algoritmes optimaliseren, 100 features toevoegen en de nieuwe code niet 'teruggeven'.
Persoonlijk zou ik niet voor de MS-RL kiezen omdat het nagenoeg geen verschil in resultaat heeft als de MIT / BSD 3-Clause / X11.
Je hebt ook eenmaal een groep mensen die denigrerend doen over dingen die een referentie naar Microsoft hebben, dus om die groep te bereiken ligt het voor de hand om een licentie die niet uit huize Redmond komt.
Overigs pas ik dezelfde mening toe over de licentie(s) uit Cupertino en MPL (en zijn afgeleiden).
[Reactie gewijzigd door RoestVrijStaal op maandag 24 september 2012 11:11]
Waar het fout gaat met de GPL licenties is dat het alle code besmet. Als je een stuke code met MIT licentie wilt toevoegen aan een stuk GPL code wordt alles GPL. Hierdoor moeten mensen hele rare fratsen uithalen zoals de GPL code in een aparte library of zelfs een aparte applicatie zetten. Hierdoor krijg je niet de, meestal, wenselijke uitbreidingen op de code terug omdat deze besmet zou worden staat deze gewoon heel ergens anders.
Met GPLv3 zijn ze helemaal te streng geworden. Het idee is dat je verbeteringen en uitbreidingen terug geeft aan de community maar clausules die dingen als 'TivoIzation' verbieden (GLPv3 code in apparaten die je niet mag modificeren) hebben daar niets mee te maken. Er zijn veel systemen waar bij het niet wenselijk is dat gebruikers zomaar de code kunnen wijzigen (denk bijvoorbeeld aan game consoles waar dit cheaters in de hand zou spelen).
In mijn ogen zijn licenties zoals MS-PL, MIT en Apache dan ook veel meer open-source. De code is dan echt gratis, no-strings attached, free as in free beer en weet ik wat nog meer. Ik ben dan ook blij dat Torque onder de MIT license valt.
Met GPLv3 zijn ze helemaal te streng geworden. Het idee is dat je verbeteringen en uitbreidingen terug geeft aan de community maar clausules die dingen als 'TivoIzation' verbieden (GLPv3 code in apparaten die je niet mag modificeren) hebben daar niets mee te maken. Er zijn veel systemen waar bij het niet wenselijk is dat gebruikers zomaar de code kunnen wijzigen (denk bijvoorbeeld aan game consoles waar dit cheaters in de hand zou spelen).
In mijn ogen zijn licenties zoals MS-PL, MIT en Apache dan ook veel meer open-source. De code is dan echt gratis, no-strings attached, free as in free beer en weet ik wat nog meer. Ik ben dan ook blij dat Torque onder de MIT license valt.
Licenties zoals MIT, BSD en Apache zijn ideaal voor bedrijven als Apple, om het werk van 1000den vrijwilligers te kapen, te monopoliseren door het te combineren met een vereiste closed source API en het vervolgens te verkopen.
Dat was echt niet wat de developers in gedachten hadden toen ze die licenties opstelden. Nadat duidelijk werd dat slinkse doch slimme bedrijven miljarden winst konden halen uit de barmhartigheid van andermans gratis code is juist die GPL opgesteld om te voorkomen dat dergelijk (in veler FOSS community's ogen) asociaal gedrag nog langer mogelijk was.
GPL komt meer op voor de belangen van de open-source community. MIT, BSD en Apache zijn interessanter voor commerciële partijen wegens kaapbaarheid, en bij wijze van compromis is de lesser-GPL (LGPL) opgesteld. Dat mag in ieder geval meegecompileerd worden, maar updates aan de code van het LGPL-onderdeel zelf moeten nog wel vrijgegeven worden. Daarmee is het probleem dat roy-t schetst opgelost.
Dat was echt niet wat de developers in gedachten hadden toen ze die licenties opstelden. Nadat duidelijk werd dat slinkse doch slimme bedrijven miljarden winst konden halen uit de barmhartigheid van andermans gratis code is juist die GPL opgesteld om te voorkomen dat dergelijk (in veler FOSS community's ogen) asociaal gedrag nog langer mogelijk was.
GPL komt meer op voor de belangen van de open-source community. MIT, BSD en Apache zijn interessanter voor commerciële partijen wegens kaapbaarheid, en bij wijze van compromis is de lesser-GPL (LGPL) opgesteld. Dat mag in ieder geval meegecompileerd worden, maar updates aan de code van het LGPL-onderdeel zelf moeten nog wel vrijgegeven worden. Daarmee is het probleem dat roy-t schetst opgelost.
[Reactie gewijzigd door Redsandro op maandag 24 september 2012 12:56]
Ze kapen het niet, ze monopoliseren het niet, de ontwikkelaars geven het weg. En niet alleen aan "bedrijven als Apple" maar echt aan iedereen. Software verdwijnt nu eenmaal niet als je het deelt. Iedereen kan er mee verder en zelf kiezen hoe ze bijdragen.
Dat was echt wel wat de ontwikkelaars in gedachten hadden toen ze die licenties opstelden. Er komen onder die licenties nog steeds grote nieuwe projecten en producten uit en niet omdat de ontwikkelaars dom zijn en niet weten wat er mee gaat gebeuren. GPL brengt met z'n politiek en allerlei beperkingen mee die niet in het voordeel zijn voor de eindgebruiker, kijk maar naar GCC vs LLVM.
Een cadeau met allerlei restricties is geen cadeau.
Dat was echt wel wat de ontwikkelaars in gedachten hadden toen ze die licenties opstelden. Er komen onder die licenties nog steeds grote nieuwe projecten en producten uit en niet omdat de ontwikkelaars dom zijn en niet weten wat er mee gaat gebeuren. GPL brengt met z'n politiek en allerlei beperkingen mee die niet in het voordeel zijn voor de eindgebruiker, kijk maar naar GCC vs LLVM.
Een cadeau met allerlei restricties is geen cadeau.
wat een onzin, bedrijf x JAT letterlijke alle code bij elkaar die het kan vinden, doet daar een eigen sausje bij en verneukt zijn klanten door lekken die gewoon gefixt zijn upstream niet toe te voegen aan jouw apparaat... kortom je zit met een ding waar productie fouten in zitten (code is ook productie).. maar waarvan het bedrijf zegt dat er geen oplossing is...
vind je het dan redelijk dat ik effectief wordt tegen gehouden om de software van MIJN apparaat op eigen kosten wel te fixen?
dat gelul over tegen piraterij is ONZIN.. want dat is al strafbaar en er zijn genoeg middelen om dat tegen te houden, 1 daarvan is je software helemaal zelf ontwikkelen en dichttimeren (zoadat niemand het wil hebben, en er dus ook geen piraterij mee zal gebeuren)...
GPL staat voor de vrijheid van iedereen... niet alleen voor de grijgrage geldbeluste code-jatters... en als je dynamic links wilt, LGPL is daar speciaal voor bedoeld..
vind je het dan redelijk dat ik effectief wordt tegen gehouden om de software van MIJN apparaat op eigen kosten wel te fixen?
dat gelul over tegen piraterij is ONZIN.. want dat is al strafbaar en er zijn genoeg middelen om dat tegen te houden, 1 daarvan is je software helemaal zelf ontwikkelen en dichttimeren (zoadat niemand het wil hebben, en er dus ook geen piraterij mee zal gebeuren)...
GPL staat voor de vrijheid van iedereen... niet alleen voor de grijgrage geldbeluste code-jatters... en als je dynamic links wilt, LGPL is daar speciaal voor bedoeld..
Het gebruik van het woord 'besmetten' is FUD; bij gewone copyrighted code onder licentie spreek je ook niet over 'besmetting' omdat je voor alle derivaten een licentie moet aanschaffen.
GPL is wel gratis te gebruiken, maar niet gratis te verkopen. Alleen de kosten zitten in het vrijgeven van je code ipv licentiekosten.
Overigen is cheaten zo oud als het gamen zelf, om het als excuus te gebruiken om je niet aan je licentievoorwaarden te houden vind ik nogal zwak.
Overigens geloof ik dat MIT/BSD wel met opzet door bedrijven te gebruiken zijn, omdat het met overheidsgeld ontwikkelde technologie betreft.
GPL is wel gratis te gebruiken, maar niet gratis te verkopen. Alleen de kosten zitten in het vrijgeven van je code ipv licentiekosten.
Overigen is cheaten zo oud als het gamen zelf, om het als excuus te gebruiken om je niet aan je licentievoorwaarden te houden vind ik nogal zwak.
Overigens geloof ik dat MIT/BSD wel met opzet door bedrijven te gebruiken zijn, omdat het met overheidsgeld ontwikkelde technologie betreft.
En daar zijn goede redenen voor, de GNU licentie is er (kort door de bocht) op gericht om open source projecten te ondersteunen: De GNU GPL stelt dat je de gemaakte software zelf mag doorontwikkelen en zelfs verkopen , als je dat recht ook doorgeeft aan anderen en de makers van de originele software vermeld. In de praktijk komt dat er op neer dat je inderdaad aan verplichtingen vast zit zoals het openbaar maken van broncode aanpassingen die je hebt gedaan.
Zeker voor commerciële partijen kan dit inderdaad gezien worden als limiterend maar is dus gedaan om te voorkomen dat een commerciële partij je code pakt, compiled en verkoopt terwijl het nog wel mogelijk blijft voor mensen om bij te dragen of hun eigen versie te ontwikkelen.
Het is dus een licentie die ontwikkelt is met een bepaalde visie over OSS in gedachte en het is aan ontwikkelaars zelf om te bepalen of ze hem gebruiken.
De MIT-licentie is inderdaad een OSS licentie aan de andere kant van het spectrum die in feite alles toestaat mits er in alle kopieën het copyright statement blijft staan.
Net zoals de BSD licentie geeft deze OSS licentie voor commerciële partijen wat meer mogelijkheden, maar als ontwikkelaar loop je dus de kans dat een commerciële partij je code gebruikt en er succesvol van profiteert terwijl jij er nooit wat van terug ziet.
Het kiezen van de licentie is dus helemaal afhankelijk van wat je verwachtingen zijn van de code die je publiceert en wat je er later zelf mee wil doen.
Zeker voor commerciële partijen kan dit inderdaad gezien worden als limiterend maar is dus gedaan om te voorkomen dat een commerciële partij je code pakt, compiled en verkoopt terwijl het nog wel mogelijk blijft voor mensen om bij te dragen of hun eigen versie te ontwikkelen.
Het is dus een licentie die ontwikkelt is met een bepaalde visie over OSS in gedachte en het is aan ontwikkelaars zelf om te bepalen of ze hem gebruiken.
De MIT-licentie is inderdaad een OSS licentie aan de andere kant van het spectrum die in feite alles toestaat mits er in alle kopieën het copyright statement blijft staan.
Net zoals de BSD licentie geeft deze OSS licentie voor commerciële partijen wat meer mogelijkheden, maar als ontwikkelaar loop je dus de kans dat een commerciële partij je code gebruikt en er succesvol van profiteert terwijl jij er nooit wat van terug ziet.
Het kiezen van de licentie is dus helemaal afhankelijk van wat je verwachtingen zijn van de code die je publiceert en wat je er later zelf mee wil doen.
Wat onzin is, een commerciële partij mag nog steeds je code pakken, compilen en verkopen. Het enige wat GPL hen verplicht is dat ze de aanpassingen dan wel publiek beschikbaar moeten maken. Het jammere is alleen dat het niet alleen bij aanpassingen blijft, maar alles erin trekt waar de GPL code mee linkt. Een applicatie releasen waarbij zowel een GPL library als een proprietary library worden gebruikt is dus al niet mogelijk.Zeker voor commerciële partijen kan dit inderdaad gezien worden als limiterend maar is dus gedaan om te voorkomen dat een commerciële partij je code pakt, compiled en verkoopt
[Reactie gewijzigd door .oisyn op maandag 24 september 2012 11:56]
Nee, ze hoeven deze aanpassingen niet publiek beschikbaar te maken.
De aanpassingen moeten aangeboden worden aan de persoon die de software koopt. Die mag dat zelf best geheim houden als hij/zij daarvoor kiest.
De aanpassingen moeten aangeboden worden aan de persoon die de software koopt. Die mag dat zelf best geheim houden als hij/zij daarvoor kiest.
Jawel. Iedereen mag de source code opvragen.Nee, ze hoeven deze aanpassingen niet publiek beschikbaar te maken.
Nope, iets ingewikkelder, het product moet worden vergezeld met de broncode (dus dan heeft alleen de afnemer van het product de broncode) die mag dan weer kiezen wat hij er mee doet.
From the horse's mouth :
http://www.gnu.org/licens...-faq.html#CanIDemandACopy
From the horse's mouth :
http://www.gnu.org/licens...-faq.html#CanIDemandACopy
Verkeerde vraag
"If I know someone has a copy of a GPL-covered program, can I demand he give me a copy?"
someone is niet de distributor van GPL-covered program, dus je kan niks van hem eisen.
"If I know someone has a copy of a GPL-covered program, can I demand he give me a copy?"
someone is niet de distributor van GPL-covered program, dus je kan niks van hem eisen.
Someone is iedereen die een kopie heft van een programma dat onder de GPL valt. Dus ook de distribiteur.
GNU GPL is er puur om open source projecten open source te houden. MS-RL geeft een hoop vrijheid, maar minder plichten, imho geeft dat de developer meer vrijheid, maar de software een stuk minder (en daardoor de gebruiker). MIT stript helemaal alle verplichtingen weg (behalve behoud van copyright en license notice).
Vijrheid om code te jatten...tja, dat is inderdaad een soort vrijheid maar het zorgt ervoor dat developers niet zo snel genegen zullen zijn om aan je project bij te dragen.
Ik heb één spel veel gespeeld dat gemaakt was met deze engine en dat was Minions of Mirth. Dat was een indy MMORPG van Prairy Games. Erg vermakelijk en nog steeds te spelen voor 30 dollar en daarna onbeperkte toegang. Het werkt als MMORPG ook op de Mac, waardoor het onder Mac-gebruikers vrij populair was.
Grafisch was ik niet onder de indruk van de engine. Het zag er uit als een game uit 2001, terwijl de game wel 100% van je machine vroeg. Je kunt er met Python tegen aan praten, maar Python zelf is vrij langzaam. Wellicht dat daar ook een oorzaak zat.
Grafisch was ik niet onder de indruk van de engine. Het zag er uit als een game uit 2001, terwijl de game wel 100% van je machine vroeg. Je kunt er met Python tegen aan praten, maar Python zelf is vrij langzaam. Wellicht dat daar ook een oorzaak zat.
Python is niet 'vrij langzaam', het is snel zat voor van alles en nog wat. Daarnaast gok ik dat python niet gebruikt wordt om te renderen in deze, en dus dat de grafische capaciteiten van de engine niet afhangen van een eventuele traagheid in python.
De grafische capaciteiten van je engine zijn wel gebonden aan hoe lang het duurt voor de logica van een frame te berekenen. Het tekenen van een 2D plaatje met een simpele lijn kan uren duren als jij een of andere berekening er voor op zet die veel resources vraagt.
Dus als jij veel van je game logica (physics bijvoorbeeld) in Python schrijft kan dat wel degelijk vertraging opleveren. Vooral omdat Python een script taal is. Het kan zijn dat de engine die Python mee compileert naar iets anders wat de boel weer zou kunnen versnellen uiteraard.
De laatste Penny Arcade adventures is niet meer met Torque gebouwd, Hothead games gebruikte deze maar Zeboyd die de laatste maakte niet.
Dus als jij veel van je game logica (physics bijvoorbeeld) in Python schrijft kan dat wel degelijk vertraging opleveren. Vooral omdat Python een script taal is. Het kan zijn dat de engine die Python mee compileert naar iets anders wat de boel weer zou kunnen versnellen uiteraard.
De laatste Penny Arcade adventures is niet meer met Torque gebouwd, Hothead games gebruikte deze maar Zeboyd die de laatste maakte niet.
De laatste PA game is niet meer in Torque gebouwd omdat Zeboyd een eigen adventure game engine heeft waar ze erg productief mee zijn 
.
Verder klopt het dat je scripttaal invloed heeft op je totale performance, maar meestal wordt een scripttaal gebruikt voor dingen die weinig impact hebben. Zoals bijvoorbeeld wat spel regels, dingen die je inventory beïnvloeden etc... Je physics engine in de scriptaal van de engine implementeren is dan weer niet de bedoeling natuurlijk.
Overigens kan ik niets vinden over Python icm met Torque3D, behalve een community project. De 'officiële' script taal voor Torque3D is hun eigen TorqueScript.
.Verder klopt het dat je scripttaal invloed heeft op je totale performance, maar meestal wordt een scripttaal gebruikt voor dingen die weinig impact hebben. Zoals bijvoorbeeld wat spel regels, dingen die je inventory beïnvloeden etc... Je physics engine in de scriptaal van de engine implementeren is dan weer niet de bedoeling natuurlijk
.Overigens kan ik niets vinden over Python icm met Torque3D, behalve een community project. De 'officiële' script taal voor Torque3D is hun eigen TorqueScript.
Blijft een favoriete uitspraak van mensen dat een programmeertaal langzaam is. De meeste voorkomende is Java, dat zou ook traag zijn.Python is niet 'vrij langzaam', het is snel zat voor van alles en nog wat.
Maar het feit is dat programmeertalen niet traaf kunnen zijn in executie. De runtime (VM, intepreter of runtime library) kan traag zijn.
CPython, de reference implementatie, is een van de langzaamste implementaties. Jython, welke in Java draait, is een stuk sneller. En PyPy, welke in python zelf geschreven is, is zelfs 5 keer sneller dan CPython.
Tribes mooie tijden
Ik moet zeggen dat Tribes:Revengance bij uitstek de beste was
Precies, ik heb veel uren in Tribes 2 gestopt, jammer dat dergelijke games uitgestorven zijn 
Moet zeggen dat het een beetje tegenvalt, tuurlijk is het leuk en zal het je veel tijd besparen, maar ik zou dan toch voorstellen om voor een wat snellere (nieuwere) 3d engine te gaan en zelf je models maken.
Nu is het natuurlijk wachten op het eerste "aliens vs marines" spel dat gewoon alle standaard models gebruikt maar wel volle prijs vraagt.
Nu is het natuurlijk wachten op het eerste "aliens vs marines" spel dat gewoon alle standaard models gebruikt maar wel volle prijs vraagt.
Ik denk dat vrijweinig mensen niet zelf models maken, maar textures (vooral voor lucht, metaal, hout enz.) zijn wel handig. Maar daar zijn tig gratis alternatieven voor.
Ook models voor wat basis objecten kunnen handig zijn of als onderdeel dienen voor grotere objecten. Spaart tijd.
En een gratis engine is natuurlijk altijd leuk, vooral als je spel niet hoeft te concureren met Frostbite 2 spellen.
Ook models voor wat basis objecten kunnen handig zijn of als onderdeel dienen voor grotere objecten. Spaart tijd.
En een gratis engine is natuurlijk altijd leuk, vooral als je spel niet hoeft te concureren met Frostbite 2 spellen.
Alhoewel er wel cross-platform code in zit, compiled hij momenteel alleen op Windows en als je hem met hacks toch aan de praat krijgt is het extreem buggy.
Ik ben weinig onder de indruk van het filmpje. Die regen-'effecten' zijn al helemaal om te huilen.
Is het niet zinvoller om voor een eventueel project de Id-Tech engine te gebruiken? Doom 3 ziet er een stukkkk beter uit dan bovenstaand filmpje, en als je lol wilt hebben met polygoonloze curves kan je ook de Quake-3 engine gebruiken. Volgens mij deed zelfs de oude Quake3 engine niet onder voor wat het Torque filmpje ons laat zien.
Id Tech engines op github:
https://github.com/id-Software
Een voorbeeld van een open source spel op basis van de Quake3 engine is OpenArena. Het ziet er niet uit, maar volgens mij is de dynamische belichting veel netter. Verder is dat eerste aspect meer de schuld van de developers die lompe platte levels en idem textures maken.
Is het niet zinvoller om voor een eventueel project de Id-Tech engine te gebruiken? Doom 3 ziet er een stukkkk beter uit dan bovenstaand filmpje, en als je lol wilt hebben met polygoonloze curves kan je ook de Quake-3 engine gebruiken. Volgens mij deed zelfs de oude Quake3 engine niet onder voor wat het Torque filmpje ons laat zien.
Id Tech engines op github:
https://github.com/id-Software
Een voorbeeld van een open source spel op basis van de Quake3 engine is OpenArena. Het ziet er niet uit, maar volgens mij is de dynamische belichting veel netter. Verder is dat eerste aspect meer de schuld van de developers die lompe platte levels en idem textures maken.
[Reactie gewijzigd door Redsandro op maandag 24 september 2012 13:14]
Open source is een mooi initiatief. Het probleem is niet dat gebruik gemaakt wordt van de source. Het probleem is dat er nooit meer wat terug komt. Geen donaties, of bugfixes. In tegendeel zelfs, gebruikers verwachten dat ze dezelfde rechten hebben als bij commerciële bedrijven. Wat dat betreft vind ik het bijzonder dat projecten zoals firefox, etc het nog zo lang volhouden. Ik geloof niet meer in open source als verdien model. Leuke kleine stukjes werk delen e.d. daar is open source prima geschikt voor.
Hangt van de licentie af, bij de MIT komt er waarschijnlijk weinig terug, verder is het verdienmodel van veel commerciele OSS projecten juist het verdienen van geld dmv van service(s) ipv een licentie op gebruik.
Ondersteuning van commerciele producten is vaak slechter/kostbaarder dan bij OSS, zoveel "rechten" heb je daar vaak niet
Ondersteuning van commerciele producten is vaak slechter/kostbaarder dan bij OSS, zoveel "rechten" heb je daar vaak niet
[Reactie gewijzigd door blouweKip op maandag 24 september 2012 16:45]
Dat snap ik niet, kijk naar Linux daar wordt heel veel gedoneert maar ook andere open source intiatieven zoals Apache of OpenSSL de community is heel groot.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Asus Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
