Open Source Lasergame/Laser Tag

[Verwijderd]

Ben eventueel bereid straks na het werk men code omtrent het Milestag protocol (16 bits + pariteit) zend en ontvang te posten, weet echter niet of iemand hier er iets mee is aangezien het in 8052 assembler is geschreven.

@ Sprite; de basisstations ed kunnen idd hetzelfde gehouden worden, mss dmv dipswitches de mode instelbaar maken? eventueel achter een klepje ofzo waar dan de verschillende modi / posities genoteerd staan.

Mbt de SD kaart; is idd het makkelijkst gewoon als SPI eeprom te gebruiken, alleen moet je dan wel via je gun / pack nieuwe geluiden uploaden, maar zou zowieso makkelijk zijn om een stuk software voor de PC te schrijven wanneer we pack inpluggen op pc dat je nieuwe game/geluiden etc etc kan uploaden.. 2gb SD kaart kost tegenwoordig toch geen k*k meer, en makkelijker dan nog extra eeprom op de printen te bakken

/edit: effe compleet verkeerd antwoord op de vraag, ik bedoelde dus dat je dmv de dipswitches verschillende ID's uitzend die je pack dan uitleest en adh hiervan beslist wat er moet gebeuren.
Past dan ook weer beter in het hele VM verhaal waarbij je soort van game beslist wat er moet gebeuren bij welk event.

[ Voor 15% gewijzigd door Verwijderd op 19-03-2007 14:03 ]

[Scout77]

Mij lijkt het handigste de basisstations ed voor het spel in te stellen met behulp van een extra kasje, net als bij fragtag (niet milestag). Dipswitches lijkt me minder handig zijn iets te veel opties voor (naar mijn mening) en moet je dat ook weer gaan beveiligen voor veranderingen tijdens het spel. IR zender en ontvanger zitten er ook al in dus kun je die mooi gebruiken.

Met het milestag protocol worden add health en ammo als een systemmsg verstuurd, zonder enig ID. (daarvan zijn er nog 14 vrij kan dus nog mooi worden uitgebreid)

Bij het basisstation en als je wilt utility-boxes heb je nog een instelling nodig voor team ID, zodat alleen dat team punten kan "afschieten" of dingen ontvangen. Instellen voor het spel, bij 'capture the flag'-variant weer tijdens het spel.

Granaten lijkt me een andere categorie want je heb ook nog een speler ID nodig die bij het ontploffen moet worden meegestuurd. Dus een of andere leermomentje tijdens het spel.

... hum als ik dit net even teruglees lijken ze ineens wel veel op elkaar, alleen de afwikkeling van wat er moet gebeuren na ontploffen, vrijgeven goodies, verminderen punten, overname team.
Och, als alles in een pic/avr/oid past kan het ook wel worden samengevoegd.

[Loy]

quote: http://gathering.tweakers.net/forum/quote_message/27695277/7

quote:
[...]
Wat is er mis met een polsbandje met LCD schermpje ?

Met een rits ledjes op je rugzak kunnen anderen ook zien hoe levend je nog bent. En het is handiger een bijna-dode af te schieten, dan iemand die nog 100% is.
Maar dat is dus van later zorg.

[ Voor 44% gewijzigd door Loy op 19-03-2007 15:32 ]

[JanPaul123]

Ik zal vanavond alles posten wat ik tot nu toe heb.

En nog even over die VM. We kunnen die later altijd nog inbouwen. Ik denk dat het nu gewoon veel te veel werk is om dat te programmeren. Zo'n VM is gewoon een project op zich. Sprite, jij bent de enige hier (tot nu toe) die dat kan, en je zei dat je waarschijnlijk binnenkort het weer druk hebt met andere dingen dus dat helpt gewoon niet. Ook zullen we op korte termijn geen andere systemen willen maken die dit ondersteunen, het lijkt me wat ambitieus om dat gelijk te doen. Laten we eerst zonder een VM een mooi systeem proberen te maken, en als dan blijkt dat het echt voordelen kan bieden kunnen we altijd onze code porten en een VM maken.

[Tp21]

ik ben het met sprite eens, zo veel werk is het niet om een VM te schrijven, het is niet meer dan een grote switch als je het heel simpel bouwt. het lijkt veel meer werk dan het eigenlijk is, en je hebt er later veel meer plezier van, omdat je systeem veel makkelijker uitbereidbaar word. afhankelijk waarvan je je uC in gaat programmeren is het niet zo bijster moeilijk een simpele VM te maken.

[Verwijderd]

Loy schreef op maandag 19 maart 2007 @ 15:25:
[...]

Met een rits ledjes op je rugzak kunnen anderen ook zien hoe levend je nog bent. En het is handiger een bijna-dode af te schieten, dan iemand die nog 100% is.
Maar dat is dus van later zorg.

Ik ben eigenlijk niet voor een rugzak, de elektronica kan je wel klein genoeg maken om in je (binnenzak) van je pak te dragen.

De voeding is natuurlijk nog een belangrijk element hierin, maar die kan je pas later bepalen.
Ik denk dat de optie 'backup' batterij voor je main unit en 'vermogen' batterij voor je gun tot nu toe het beste is.

[Verwijderd]

Tp21 schreef op maandag 19 maart 2007 @ 15:41:
ik ben het met sprite eens, zo veel werk is het niet om een VM te schrijven,

Ik denk dat 'knopendoorhaken' voor zich spreekt ivm VM al dan niet.
Ik ken hier niets van laat dat duidelijk zijn, maar is het niet beter om nu de knoop ook daadwerkelijk door te hakken en effectief hieraan werken ipv een wel/niet discussie ? No offence !

[Tp21]

Verwijderd schreef op maandag 19 maart 2007 @ 15:48:
[...]


Ik denk dat 'knopendoorhaken' voor zich spreekt ivm VM al dan niet.
Ik ken hier niets van laat dat duidelijk zijn, maar is het niet beter om nu de knoop ook daadwerkelijk door te hakken en effectief hieraan werken ipv een wel/niet discussie ? No offence !

no offence taken, je hebt eigenlijk wel gelijk, maar ik ben stiekem wel voorstander van een VM

[Loy]

Om nu al daadwerkelijk met hardware aan de gang enzo te kunnen gaan is een VM niet belangrijk, maar later wel, vanwege de genoemde voordelen.
De hardware aansturen moet sowieso, met of zonder VM, dus daar kan al wel een begin mee gemaakt worden.

Persoonlijk zou ik wel een rugzak maken, puur omdat ik het wel fijn vind ergens, en het voelt misschien wel wat realistischer. Nodig is het zeker niet, maar ik vind het wel wat hebben.

Gelukkig kan iedereen dus voor zichzelf beslissen.

[brainwave modus]
Voor het ontwerp van software:
kan er niet een centraal stuk zijn dat "gewoon" alle stats als health, ammo, vlag, etc. bijhoudt, en dit eventueel op een (per stat gespecificeerde) analoge/digitale poort of adres zet, zodat custom onderdelen dit uitlezen? Zo hoef je geen standaard support voor een LCD oid in te bouwen, maar kan dit door een uitbreiding naar een LCD of LED-array gestuurd worden.
[/brainwave modus]

[Scout77]

Tot nu toe heb ik het idee dat de meesten een VM wel een goed idee vinden, maar er zijn maar weinig mensen die het ook daadwerkelijk begrijpen en werkende kunnen maken.

Grootste bezwaar wat ik nu lees is dat het een overkill is en dan het teveel tijd kost. Maar een werkelijke inschatting over hoeveel tijd dit nu werkelijk gaat kosten en belangrijker eigenlijk wie zich ermee bezig wil en kan houden weten we niet. Als het alleen Sprite tm is lijkt het me niet handig maar als de groep groter is wel, en is een VM ook sneller gemaakt.

Ik zou zeggen start een pagina op de Wiki en ga aan de slag. Helaas heb ik er zelf geen kaas van gegeten dus aan mij heb je niks, ik houd me wel bezig met ander dingen.


<edit>oh en kan de image upload van de wiki ook aangezet worden?

[ Voor 6% gewijzigd door Scout77 op 19-03-2007 16:12 ]

[Verwijderd]

Leuk project is dit!
Jammer dat ik niet zoveel nuttigs kan helpen, het enige dat ik (goed) kan programmeren is php/mysql, dus misschien kan ik helpen met een site oid...

[ Voor 3% gewijzigd door Verwijderd op 19-03-2007 16:17 ]

[Tp21]

in welke taal willen we het systeem gaan schrijven, in BASIC net zoals milesTag, of c/c++ of assembly?, want misschien kan ik wel helpen (heb niet zo heel veel programmeer ervaring in c/c++/asm, maar wil best wat proberen).

[Verwijderd]

Loy schreef op maandag 19 maart 2007 @ 16:02:
[brainwave modus]
Voor het ontwerp van software:
kan er niet een centraal stuk zijn dat "gewoon" alle stats als health, ammo, vlag, etc. bijhoudt, en dit eventueel op een (per stat gespecificeerde) analoge/digitale poort of adres zet, zodat custom onderdelen dit uitlezen? Zo hoef je geen standaard support voor een LCD oid in te bouwen, maar kan dit door een uitbreiding naar een LCD of LED-array gestuurd worden.
[/brainwave modus]

Als we als communicatie middel naar de randapparaten I2C oid gebruiken, kan je aansturen wat je wil, mits een beetje kennis van de gekozen programmeertaal.

Maar als we ons systeem zo maken dat iedereen kan modden wat hij wil lijkt een GOD mode stiekem om de hoek komen te kijken.
Of kan hier softwarematig een stokje voor gestoken worden ?

[Tp21]

misschien dat het mogelijk is om de gun te 'locken' zodra het spel begint, zodat je geen instellingen meer kan veranderen, of nieuwe firmware/nieuw script kan uploaden, en voordat het spel begint iedereen het zelfde script krijgt ( ).

[Verwijderd]

Tjah, als je zelf aan het programmeren slaat kan je altijd cheaten, zoals reeds gezegd. Moet maar een beetje op de goodwill van de anderen rekenen denk ik zo :-)

Wat betreft het programmeren, i dunno.. ik denk dat hier meer C fanaten zitten dan assembly, maar op zich maakt dat principieel niet uit, als we bepaalde taken verdelen qua programmatie.

[shorttracker]

ja, en als je dan tijdens het spelen een kistje vind met daarin onzichtbaarheid (een van de god gun functies)? dan kan die godgun niet aangezet worden, of vergis ik me?

[JanPaul123]

Ok, hier wat stuff van mijn prototype

http://openlaserfrag.org/files/Prototype_1.3gp Filmpje 1
http://openlaserfrag.org/files/Prototype_2.3gp Filmpje 2
http://openlaserfrag.org/..._Prototype_19-03-2007.zip Broncode+schema's

Tp21 schreef op maandag 19 maart 2007 @ 17:03:
Gluggie, je laatste link werkt niet, ff aanpassen.

tnx.

Ik zal later alles even beschrijven e.d. Nu even geen tijd voor .

Scout77 schreef op maandag 19 maart 2007 @ 17:15:
Ziet er goed uit. Kan begrijpen dat je niet zo'n zin hebt te wachten op een VM versie

Hehe. Maar opzich is een VM hier goed in te implementeren hoor. Er is al heel veel abstract. De interface.c zou dan moeten worden herschreven naar een VM, die knoopt alle abstracte dingen aan elkaar.

[ Voor 73% gewijzigd door JanPaul123 op 19-03-2007 17:18 ]

[Tp21]

shorttracker schreef op maandag 19 maart 2007 @ 16:56:
ja, en als je dan tijdens het spelen een kistje vind met daarin onzichtbaarheid (een van de god gun functies)? dan kan die godgun niet aangezet worden, of vergis ik me?

nee, godgun functies zijn functies als admin-kill, game starten, game stoppen, etc. onzichtbaarheid zou een bonus funcite zijn, en je zou het helemaal aan de VM over kunnen laten natuurlijk.

Gluggie, je laatste link werkt niet, ff aanpassen.

[ Voor 5% gewijzigd door Tp21 op 19-03-2007 17:12 ]

[Phalox]

Wooow.. stop dreaming Jullie gaan er nogal vandoor met brainstormen, maar er moet wel eerst een basis zijn. Nu lijkt het alsof er nooit iets van de grond zal komen.
Wat wou ik dat ik C-pro was, dan kon ik meehelpen, nu kan ik alleen kijken en proberen snappen wat er staat En nu nog 'even' kijken op de wiki wat daar nog allemaal gebeurt is.)

[shorttracker]

Sweet
ik moet zeggen, ik vind die Reload helemaal te gek! dat heb je echt super vet gedaan.
Ik snap alleen die burst niet??? wat is dat?
(is burst zegmaar in machinegeweer functie? dat de kogels er achter elkaar uitvliegen?)

[ Voor 23% gewijzigd door shorttracker op 19-03-2007 17:11 ]

[JanPaul123]

shorttracker schreef op maandag 19 maart 2007 @ 17:10:
Sweet
ik moet zeggen, ik vind die Reload helemaal te gek! dat heb je echt super vet gedaan.
Ik snap alleen die burst niet??? wat is dat?

Das een burst-fire van 3 schoten. Hebben sommige echte geweren ook. (Is uiteraard uit te schakelen )

[Scout77]

Gluggie schreef op maandag 19 maart 2007 @ 16:59:
Ok, hier wat stuff van mijn prototype

http://openlaserfrag.org/files/Prototype_1.3gp Filmpje 1
http://openlaserfrag.org/files/Prototype_2.3gp Filmpje 2
[url]OpenLaserFrag_Prototype_19-03-2007.zip[/url] Broncode+schema's

Ziet er goed uit. Kan begrijpen dat je niet zo'n zin hebt te wachten op een VM versie

ps zip werkt niet spuit elf

[ Voor 3% gewijzigd door Scout77 op 19-03-2007 17:16 ]

[shorttracker]

ahh, ja ik zie het nu in de broncode.
Ik had al wel gezien dat er iets veranderde, hij ging veel sneller.
Maargoed, complimenten
Nu gaan we het eens lekker uitbereiden/veranderen

[Tp21]

is die 18Fnogwat PIC nog een beetje goedkope programmer voor te krijgen? want ik wil zelf ook wel eens wat meer prutsen met wat nieuwere PIC's dan de 16F648A.

[ Voor 42% gewijzigd door Tp21 op 19-03-2007 17:18 ]

[Phalox]

Op Video.google:

Filmpje 1: http://video.google.nl/videoplay?docid=2069244720857148297
Filmpje 2: http://video.google.nl/videoplay?docid=7568770187143132877

--> altijd handig voor mensen die niet zo direct quicktime player op hun computer hebben staan.

[Aapenootjes]

Ik volg dit topic al een paar dagen, geweldig idee! Toevallig heb ik vorige week nog gelasergamed, dat viel helaas zwaar tegen omdat de gebruikte regels (en de locatie ook een beetje) ontiegelijk brak waren. Met een project als dit moet dat veel beter kunnen.

Het lijkt me zaak om ook een soort algeheel plan van aanpak op te stellen waarin aangegeven is wie welke taak uitvoerd, en welke taak gestart kan worden nadat 1 taak afgerond is.

Das een burst-fire van 3 schoten. Hebben sommige echte geweren ook. (Is uiteraard uit te schakelen )

Enige punt is dat dat voornamelijk is om beter te kunnen mikken in verband met de terugslag. Niet erg nuttig bij een lasergun, behalve als je te triggerhappy bent en anders in no-time door je ammo heen bent. Mocht je dit willen toepassen moet je eigenlijk alleen een soort terugslag in gaan bouwen, wat me verder niet erg haalbaar lijkt. Het idee zelf vind ik overigens wel vet.

Maar goed, dit zijn van dat soort details welke je pas in een later stadium gaat implementeren.

Als ik tijd en zin heb gooi ik wel eens wat ideëen met betrekking tot gameplay e.d. het topic in zo snel de tijd daarvoor rijp is. Met de huidige bezigheden kan ik niet veel helpen, maar ik zal het topic wel volgen en kijken of ik ooit toegevoegde waarde kan zijn.

[deugtniet]

Wat een cool project is dit zeg.
Ik ben nieuw op het forum, en kan niet programmeren, alleen een beetje basic van m'n rekenmachine. maar ik zou graag wel mee willen werken aan het ontwerp van het pak (soort kogelvrijvest idee) en de wapens (het modden van bepaalde lightguns (?))

ik zal me wel inschrijven op de wiki. jullie schoppen me er wel uit als ik niet nodig blijk te zijn.
super initiatief dit zeg! en ik zal met smart alles proberen bij te houden.

misschien is het handig dat ik gelijk ook een toevoeging doe aan het pak. zoals hierboven gezegd lijkt mij een vest met een soort stevige cover erover heen heel goed omdat je er (relatief gemakkelijk) modules op kan zetten waar sensoren in zitten.

[ Voor 21% gewijzigd door deugtniet op 19-03-2007 20:26 . Reden: i had a brainwave ]

[Stoney3K]

Sjemig wat je kan missen als je een weekendje naar een LAN geweest bent.

Er zijn op elektronica-gebied al ontzettend veel ideeën voorbij gekomen, waarvan sommigen me zeker aanspreken, zoals het VM-idee van Sprite (dan maakt één developer bv. een core voor Atmel, een ander voor PIC, enz..). Ik heb zelf met coden wel ervaring (programmeren in C en high-level) maar solderen is niet echt mijn sterkste punt

Waar we ook nu naar moeten gaan kijken zijn de behuizingen voor de "wapens". Je zit in Nederland voor een deel met een probleem als je replica's van echt bestaande wapens wilt gebruiken, sinds die voor de Nederlandse wapenwet als nepwapens (voorwerpen voor afdreiging geschikt) aangeschreven zijn.

Het punt is een beetje dat er niet goed in de wet staat HOEVEEL een vermeende replica op zijn echte broer moet lijken om nog als replica herkend te worden. Voorbeeld: ik heb hier een 75% schaalmodel van een MP5SD liggen en een blok hout dat voor een behoorlijk deel in de vorm van een P90 is gezaagd. Beide lijken niet 100% op hun echte voorbeeld, maar is dat voor de wet genoeg? Ik wil niet dalijk het risico lopen dat we flinke boetes oplopen als we aan het spelen zijn, en ik wil ook niet met knalgroene speelgoed-sci-fi-wapens rondlopen als ik mijn camouflagekleding aanheb.

Ik wil me best bezig houden met de "equipment side" van het sytsteem, dus fysieke ontwerpen van guncasings, packs, enzovoort, voor een groot deel gebaseerd op de huidige militaire uitrusting zodat we veel onderdelen gewoon in de gemiddelde dumpzaak kunnen kopen. Voor een sensorvest kun je bijvoorbeeld goed een tactical vest halen voor een paar tientjes en met klittenband daar de domes op bevestigen.

[Stoney3K]

Tp21 schreef op maandag 19 maart 2007 @ 17:03:
[...]


nee, godgun functies zijn functies als admin-kill, game starten, game stoppen, etc. onzichtbaarheid zou een bonus funcite zijn, en je zou het helemaal aan de VM over kunnen laten natuurlijk.

Hoe denk je je dat voor te stellen? Je pakt het kistje op en je verdwijnt plotseling voor alle spelers in het niets? ... We zitten nog steeds vast aan de laws of physics dus Quake-achtige powerups als onzichtbaarheid en vliegen worden een beetje lastig. Zaken als invulnerability (onkwetsbaarheid) en double/quad damage zouden wel kunnen.

[warcow]

Wat betreft de behuizing voor de guns. Hieronder een linkje naar de light gun die ik bedoelde. Ik heb de verkoper een mailtje gestuurd met de vraag hoeveel hiervan nog verkrijgbaar zijn. (is beetje zonde als jullie het hele model hierop basseren als er nog maar 10 van dezen beschikbaar zijn.)
Zodra ik reactie hierop heb zal ik wel weer even posten.

http://www.psxshop.nl/pro...th=26_133&products_id=436

[deugtniet]

Stoney3K schreef op maandag 19 maart 2007 @ 20:32:
[...]


Hoe denk je je dat voor te stellen? Je pakt het kistje op en je verdwijnt plotseling voor alle spelers in het niets? ... We zitten nog steeds vast aan de laws of physics dus Quake-achtige powerups als onzichtbaarheid en vliegen worden een beetje lastig. Zaken als invulnerability (onkwetsbaarheid) en double/quad damage zouden wel kunnen.

Nou, zoals eerder is vermeld kan je de signaal lichten uitschakelen van het pak waardoor je in het donker (haast) niet te zien bent.

[shorttracker]

Stoney3K schreef op maandag 19 maart 2007 @ 20:32:
[...]


Hoe denk je je dat voor te stellen? Je pakt het kistje op en je verdwijnt plotseling voor alle spelers in het niets? ... We zitten nog steeds vast aan de laws of physics dus Quake-achtige powerups als onzichtbaarheid en vliegen worden een beetje lastig. Zaken als invulnerability (onkwetsbaarheid) en double/quad damage zouden wel kunnen.

Met onzichtbaar bedoelen we dat de led's op je pak uitgaan (als we led's gaan gebruiken..)
Voor het vliegen kunnen we een kraan op een vaste plek neerzetten?

warcow schreef op maandag 19 maart 2007 @ 20:33:
Wat betreft de behuizing voor de guns. Hieronder een linkje naar de light gun die ik bedoelde. Ik heb de verkoper een mailtje gestuurd met de vraag hoeveel hiervan nog verkrijgbaar zijn. (is beetje zonde als jullie het hele model hierop basseren als er nog maar 10 van dezen beschikbaar zijn.)
Zodra ik reactie hierop heb zal ik wel weer even posten.

http://www.psxshop.nl/pro...th=26_133&products_id=436

Ik vraag me af of we dat kunnen gebruiken... Er moet waarschijnlijk een speaker inkomen, en het IR licht moet denk ik nog een stuk feller zijn. Verder moet je geweer je aantal kogels, klips, mode, enz.. weergeven.
Ik denk dat je beter voor zelfgemaakte wapen kan gaan.

[gerre22]

Maar waarom zou je pak zichtbaar moeten zijn? om zeker te zien dat je het aan hebt? of om te zien dat je het niet onder iets aanhebt? Imho is het leuker om te spelen a là army. Maar jah heb dan niet voor niets een tijdje erin gezeten.

Edit: en als er ne go is dan kunnen we al een beetje beginnen denken over de lay-out van het pak.

[ Voor 17% gewijzigd door gerre22 op 19-03-2007 21:34 ]

[shorttracker]

gerre22 schreef op maandag 19 maart 2007 @ 21:33:
Maar waarom zou je pak zichtbaar moeten zijn? om zeker te zien dat je het aan hebt? of om te zien dat je het niet onder iets aanhebt? Imho is het leuker om te spelen a là army. Maar jah heb dan niet voor niets een tijdje erin gezeten.

Omdat je dan kan zien bij welk team een speler hoort...

[Stoney3K]

gerre22 schreef op maandag 19 maart 2007 @ 21:33:
Maar waarom zou je pak zichtbaar moeten zijn? om zeker te zien dat je het aan hebt? of om te zien dat je het niet onder iets aanhebt? Imho is het leuker om te spelen a là army. Maar jah heb dan niet voor niets een tijdje erin gezeten.

Edit: en als er ne go is dan kunnen we al een beetje beginnen denken over de lay-out van het pak.

Op zich hoeft zo'n pak zelf niet zo opzichtig te zijn, hier een piccie van een Australisch team:



Het "pak" is bij hun alleen de sensoren op hun pet, vest, enz... en die zijn niet groot! In ons geval komt daar hooguit nog een kastje bij dat aan je riem hangt

Overigens nog een ideetje voor een guncasing:



Heavily modded and painted Nerf Longshot, assault rifle anyone?

[warcow]

Mocht er toch voor die van psxshop gekozen worden, ik kreeg net een mail terug, en ze hebben er nog ongeveer 150 liggen. :d moet wel genoeg zijn lijkt me. Deze gun heeft dus als voordeel dat ze zeer goedkoop zijn en voor iedereen te gebruiken waardoor een algemen layout moet werken. Er zitten overigens standaard 3 ledjes in, en een paar knoppen op geplakt.
Als er intresse voor is, wil ik zo'n gun wel even van binnen fotograferen ook aangezien ik er een paar van heb liggen.

[Tp21]

we moeten echt gaan beslissen hoe we het hardwarematig gaan doen, hoe modulair gaan we het maken? welk protocol gebruiken we om tussen onderdelen te praten (UART, i2C, iets anders).

offtopic:
dit topic loopt wel heel erg hard zeg! al 10 pagina's

[ Voor 17% gewijzigd door Tp21 op 19-03-2007 22:43 ]

[Stoney3K]

Tp21 schreef op maandag 19 maart 2007 @ 22:38:
we moeten echt gaan beslissen hoe we het hardwarematig gaan doen, hoe modulair gaan we het maken? welk protocol gebruiken we om tussen onderdelen te praten (UART, i2C, iets anders).

offtopic:
dit topic loopt wel heel erg hard zeg! al 10 pagina's

Voor de communicatie tussen de hardware in zou ik net als Sprite voorstelde voor een UART-based communicatie gaan met tristate transmitters, maar misschien met een verschil:

Als je een XLR kabel pakt is die standaard balanced, waarom zouden we dat dan niet gebruiken? De power kan (net als +48V phantom) DC gekoppeld worden op de signaallijnen en het signaal gaat dus gebalanceerd (een + spanning en een - spanning) de lijn op (met een inkoppeltrafo'tje). Ik weet niet of het echt hard nodig zal zijn maar het is een optie.

Voordeel van jack/XLR is dat er ook krulsnoeren voor te krijgen zijn (a.k.a. koptelefoonsnoeren) wat je met veel andere kabels moeilijk kan. Is wel zo handig als je door het veld loopt en je wil je gun op verschillende afstanden van je lijf dragen, anders is op het ene moment het snoer te kort (twang, knak!) en op het andere moment te lang (struikel)

[Verwijderd]

Ken het systeem niet goed, kan je er mss es een schets van maken? soort van de data gesuperponeerd op een DC voedingsspanning ofzow?

[shorttracker]

I2C
UART
XLR
allemaal wikipedia...

[slopert]

Ik kan niet echt goed tekenen, maar ik zal het proberen uit te leggen.

Apparaat - condensator - connector - draad - connector - voeding - condensator - signaalbron.

Je kan het apparaat voeden door tussen de condensator en de connector de voeding af te tappen. De condensator is een draad onderbreking voor gellijk stroom/spanning. Het apparaat heeft geen last van de voeding, maar je mist wel 1 of twee draden om de voeding te transpoteren. Dit is het princiepe een fantoom voeding.

Maar als ik er een beetje over nadenk zou dit niet echt werken voor hoge frequenties. Tot 20 kHz zou dit geen probleem moeten geven. Op uC nivo zouden de flanken veel te vlak worden en niet meer bruikbaar zijn.

[ Voor 19% gewijzigd door slopert op 20-03-2007 09:10 . Reden: klein foutje ]

[Scout77]

We lopen een beetje vast op het VM wel/niet naar mijn idee .

Hier moet een knoop worden doorgehakt .... kijk even op:
http://www.openlaserfrag.org/wiki/index.php/KnopenHakken

[Stoney3K]

slopert schreef op maandag 19 maart 2007 @ 23:50:
Ik kan niet echt goed tekeken, maar ik zal het proberen uit te leggen.

Apparaat - condensator - connector - draad - connector - voeding - condensator - signaalbron.

Je kan het apparaat voeden door tussen de condensator en de connector de voeding af te tappen. De condensator is een draad onderbreking voor gellijk stroom/spanning. Het apparaat heeft geen last van de voeding, maar je mist wel 1 of twee draden om de voeding te transpoteren. Dit is het princiepe een fantoom voeding.

Maar als ik er een beetje over nadenk zou dit niet echt werken voor hoge frequenties. Tot 20 kHz zou dit geen probleem moeten geven. Op uC nivo zouden de flanken veel te vlak worden en niet meer bruikbaar zijn.

Je kan het beter zien door te Wikipedia'en op Phantom Power:

http://en.wikipedia.org/wiki/Phantom_power

[Stoney3K]

Ik denk dat we trouwens ook wat aan promotie hier en daar moeten doen, als we laten zien wat we aan het ontwikkelen zijn krijgen we misschien wel genoeg spelers mee. Het zou bijvoorbeeld leuk zijn als we de Elektuur kunnen halen.

[Verwijderd]

Ik was ook even wat aan het brainstormen

Het zou natuurlijk leuk zijn als je meerdere wapens bij je kunt dragen, bijvoorbeeld je main(assault)-gun, en nog een handpistool. Zodat als je aan het herladen bent en je ziet plotseling een enemy dat je je handgun nog snel uit de holster kunt trekken

Het zou leuk zijn als er meerdere schiet-opties op het wapen zitten, bijvoorbeeld single-shot, burst en auto fire.

Misschien een base-station waar je naartoe moet als je geraakt bent. Dit station zou dan bijvoorbeeld een ir-signaal kunnen uitzenden waarbij je minimaal 5 seconden in de buurt moet zijn om weer te respawnen. Dit base station kan dan bijvoorbeeld 50 meter van de vlag vandaan staan in het geval van ctf.
Bij dit base station zou je dan ook health en ammo kunnen halen (ook met een ir-signaal)

[Sprite_tm]

Stoney3K schreef op dinsdag 20 maart 2007 @ 01:42:
Ik denk dat we trouwens ook wat aan promotie hier en daar moeten doen, als we laten zien wat we aan het ontwikkelen zijn krijgen we misschien wel genoeg spelers mee. Het zou bijvoorbeeld leuk zijn als we de Elektuur kunnen halen.

Mocht het wat worden, kan ik wel een leuk stukje voor de Elektuur schrijven. Ik zou even moeten overleggen, maar volgens mij kan zo'n project er makkelijk inkomen.

[Scout77]

Stoney3K schreef op dinsdag 20 maart 2007 @ 01:42:
Ik denk dat we trouwens ook wat aan promotie hier en daar moeten doen, als we laten zien wat we aan het ontwikkelen zijn krijgen we misschien wel genoeg spelers mee. Het zou bijvoorbeeld leuk zijn als we de Elektuur kunnen halen.

Make en Hackaday zijn ook leuk, alleen dan moet er denk ik toch eerst iets zijn en alles in het engels worden vertaald.

Och dan kan hacked gadget er ook nog wel bij.

Hum nog mensen hier uit Twente?

[ Voor 14% gewijzigd door Scout77 op 20-03-2007 02:35 ]

[deugtniet]

ik ga nu naar school, en ik ga proberen om daar alvast wat te tekenen over de layout van het pak.
als iemand een paar maten kunnen geven van hoe groot de printplaten er ongeveer uit moeten gaan zien. dan kan ik die gelijk ook verwerken in het pak.

misschien is het ook handig om de batterij(en) te verwerken in de (grotere) wapens.

[Verwijderd]

Meld me hier ook ff aan, voornamelijk voor programmeer werk. Lijkt me een leuk project

[Verwijderd]

Stoney3K schreef op dinsdag 20 maart 2007 @ 01:42:
Ik denk dat we trouwens ook wat aan promotie hier en daar moeten doen, als we laten zien wat we aan het ontwikkelen zijn krijgen we misschien wel genoeg spelers mee. Het zou bijvoorbeeld leuk zijn als we de Elektuur kunnen halen.

Dat is een goede optie, maar ik denk dat we met wat beters moeten afkomen dan wat we nu nog maar hebben.
Ik bedoel dat we in een verder stadia moeten verkeren en niet meer moeten twijfelen over bepaalde belangrijke zaken.

maw Onze vervelende knopen moeten eerst feiten zijn voor je naar elektuur stapt.

Ik persoonlijk vind I2C het modulairste systeem, maar dat zal ook wel liggen aan het feit dat ik minder goed thuis ben in de UART wereld. daar tegenover is I2C dan weer gevoeliger voor storingen.

[Scout77]

deugtniet schreef op dinsdag 20 maart 2007 @ 08:24:
misschien is het ook handig om de batterij(en) te verwerken in de (grotere) wapens.

Als je makkelijk guns en andere zaken in je Personal Unit (pack) wilt ompluggen lijkt het me handig als deze op zich zelf draait. Dus dan is ook een (kleine) battery nodig in je PU (Personal Unit). Lijkt me dat het PU waar alleen je leven en je scores wordt bijgehouden en waar de sensoren in zijn geplugd niet zo heel veel prik nodig heeft.

[mithras]

Jongens, het loopt nu al teveel uiteen over materiele zaken die er nu nog niet toe doen. Leuk, guns ontwerpen, lcd schermpjes uitproberen en geluidchips uitzoeken: je kan er niets mee zonder goed fundament!

Omdat ik hier weinig van snap ga ik me niet mengen in de discussie, maar op dit moment lijkt het een typisch voorbeeld te worden van een open source project wat gaat verzanden door de overbodige discussies en fantasien van de leden.

De vragen die nu eerst beantwoord moeten worden zijn volgens mij de volgende twee punten (die min of meer ook met elkaar samen hangen):
[list]• Virtual Machine of niet? Wat ik lees heeft het een aantal voordelen (maar ik kan het fout hebben):[list]• Modulair ingericht
• De feitelijke spelmodi staan los van de functies die dit project gaat ondersteunen
• Voordeel tov verschillende proc's
Maar de nadelen:[list]• Wellicht overkill voor dit project
• Het kost meer tijd om een VM te ontwikkelen
• Het bestaande ontwerp gebruikt het nietIk ga geen ordeel vellen over of een puntje wel of niet mee weegt, bepaal dat zelf.

Op de wiki hier te vinden.
• Welke proc gebruiken?
Er zijn twee voorstellen gedaan: PIC en AVR. Met beide heb ik geen ervaring (uiteraard, met wat wel ), maar het is 3 vs 3 op de wiki.
Het punt voor de PIC is dat het project hierop is begonnen, de AVR is volgens anderen wat flexibeler en laagdrempeliger. Over de compilers ga ik geen uitspraak doen
Op de wiki hier te vinden.


Dus nu: welke keuzes. Het zou mooi zijn als voor dit weekend er uitsluitsel is over deze twee zaken. Desnoods met stemming, maar misschien dat met wat discussie er wel wat uit te onderhandelen is. Hoe zit het met bijvoorbeeld VM en proc compatibiliteit: kan de vm op beide proc's draaien, of valt een van de twee al af (en dus misschien ook het vm idee)?
Als we er niet uitkomen is het zonde, want dat zal de TS zijn projectje in zn eentje doorzetten, en dat is natuurlijk niet de bedoeling. Mocht het nodig zijn, dan richt ik wel twee polletjes in

[shorttracker]

Als we een VM gaan maken, dan maakt het verder toch niet uit of we een PIC, of een AVR willen?
Die VM is dan per processor verschillend, maar de code voor de lasergame zelf niet. Dat is nou juist een van de voordelen van een VM.

Ik denk dat een VM echt, heeel erg handig is. Alleen moet de topic starter het er natuurlijk wel mee eens zijn, en dat is hij volgens mij nog niet...

Nog een vraagje: Moet de VM gemaakt worden voor de Centrale proc EN voor de gun, of maar voor één van de twee, of kunnen ze beide op de zelfde VM draaien??

[Sprite_tm]

Ik ben van plan om de VM in C te gaan schrijven. Omat het verder geen binding met de peripherials of andere hardwarematige bindingen heeft, zou de code op ieder platform wat C ondersteund, gecompileerd moeten kunnen worden. Qua proc: Als iemand mij een C-compiler die goed en gratis is en die voor het PIC-platform code kan compileren aan kan wijzen, heb ik er geen enkel bezwaar tegen om het daarop te schrijven. Als dat echter niet bestaat, ben ik er toch wel heel erg voor om het alsnog op een AVR te doen; daar is gewoon een gcc-port voor en dat zit dus wel goed qua compatibiliteit. Iemand met access tot een goede PIC-compiler kan dan altijd nog een port richting die proc doen.

Shorttracker: De gun is gewoon een randapparaat en hoeft dus geen VM te draaien. Wat evt. als we een VM gaan gebruiken wel kan, is een versie maken met de gun-firmware en de backpack-firmware geintegreerd zodat alles in de gun zit, voor degene die dat liever hebben.

[ Voor 17% gewijzigd door Sprite_tm op 20-03-2007 13:09 ]

[shorttracker]

Sprite_tm schreef op dinsdag 20 maart 2007 @ 13:06:
...
Shorttracker: De gun is gewoon een randapparaat en hoeft dus geen VM te draaien. Wat evt. als we een VM gaan gebruiken wel kan, is een versie maken met de gun-firmware en de backpack-firmware geintegreerd zodat alles in de gun zit, voor degene die dat liever hebben.

Volgens mij wil iedereen wel een personal unit, dus dan hoeft dat voor de gun niet, maar misschien handig voor later idd...

Ik heb hier 2C compilers voor je:
deze hebben we op school gebruikt, en is gratis. Ik weet alleen niet of deze wel handig is voor microprocessors, werkt wel makkelijk. Dev-C++ compiler

Dit is een demo, maar wordt volgens mij erg veel gebruikt voor microprocessors. Kan tot maximaal 2kb in de demo, maar dan moet je flink doortypen. Mikro C, voor de PIC
zelfde, alleen dan voor de AVR : Mikro C, voor de AVR

[Verwijderd]

-Deleted- shorttracker was me voor

[ Voor 93% gewijzigd door Verwijderd op 20-03-2007 13:39 ]

[JanPaul123]

shorttracker schreef op dinsdag 20 maart 2007 @ 13:33:
Dit is een demo, maar wordt volgens mij erg veel gebruikt voor microprocessors. Kan tot maximaal 2kb in de demo, maar dan moet je flink doortypen. Mikro C, voor de PIC
zelfde, alleen dan voor de AVR : Mikro C, voor de AVR

De officiele C18 compiler van Microchip zelf is ook wel goed, de Student Edition is gratis en het enige verschil is dat je niet alle optimalisaties kunt aanzetten. Ik heb zelf toegang tot de full version dus ik kan in principe de final builds daarmee compileren.

Wat betreft het Knopen Hakken, de consensus lijkt me gevormd wat betreft VM, dus vooruit. Wel stel ik voor de VM behoorlijk hoog te houden, dat wil zeggen dat we zo veel mogelijk in C implementeren en VM alles enkel aan elkaar knoopt om gameplay regels te vormen.

Zelf ben ik (dus) erg voor de PIC, niet alleen omdat Milestag en alles daar nu al geweldig mooi onder werkt door middel van interrupts, maar ook omdat het helemaal niet zo hoogdrempelig is als sommigen beweren. Het enige punt kan zijn het programmen, maar als je er eenmaal een bootloader op hebt zitten, kun je gewoon direct via USB je programma er inladen. Eventueel kan ik een heleboel PICs van een bootloader voorzien en rondsturen aan mensen die er graag een willen, zodat je alleen een USB kabeltje nodig hebt om 'em te proggen.

[ Voor 35% gewijzigd door JanPaul123 op 20-03-2007 13:56 ]

[Sprite_tm]

shorttracker schreef op dinsdag 20 maart 2007 @ 13:33:
[...]

Volgens mij wil iedereen wel een personal unit, dus dan hoeft dat voor de gun niet, maar misschien handig voor later idd...

Ik heb hier 2C compilers voor je:
deze hebben we op school gebruikt, en is gratis. Ik weet alleen niet of deze wel handig is voor microprocessors, werkt wel makkelijk. Dev-C++ compiler

Nope, deze gebruikt MingW als backend, wat een voor Windows geporte versie van gcc is. X86-only dus.

Dit is een demo, maar wordt volgens mij erg veel gebruikt voor microprocessors. Kan tot maximaal 2kb in de demo, maar dan moet je flink doortypen. Mikro C, voor de PIC
zelfde, alleen dan voor de AVR : Mikro C, voor de AVR

Leuk, maar die 2K heb je al snel; bovendien ben ik niet echt een fan van het feit dat we elke developer dan een demo-versie van een programma moeten laten gebruiken.

[slopert]

Misschien is deze bruikbaar?
http://sdcc.sourceforge.net/

Heb net snel gekeken en de beoogde pic (18F2550) staat genoemd bij de include files en in de lib directory.

Gebruik wel het laatste snap-shot http://sdcc.sourceforge.net/snap.php de release files zijn van 2006.

[Verwijderd]

Dacht ook net SDCC voor te stellen. Laatste wat ik ervan gehoord had was het wel nog niet optimaal draaiende voor pic, maar kan ondertussen veranderd zijn. Heb er allicht enkel ervaring mee op 8052 gebied.

Which brings me to the question, is er eigenlijk nood aan assembly programming? Hangt af van de C compiler zeker, of de nodige peripherals al in library aanspreekbaar zijn?

[StefSybo]

Gluggie schreef op dinsdag 20 maart 2007 @ 13:50:
Zelf ben ik (dus) erg voor de PIC, niet alleen omdat Milestag en alles daar nu al geweldig mooi onder werkt door middel van interrupts, maar ook omdat het helemaal niet zo hoogdrempelig is als sommigen beweren. Het enige punt kan zijn het programmen, maar als je er eenmaal een bootloader op hebt zitten, kun je gewoon direct via USB je programma er inladen. Eventueel kan ik een heleboel PICs van een bootloader voorzien en rondsturen aan mensen die er graag een willen, zodat je alleen een USB kabeltje nodig hebt om 'em te proggen.

Waarom zouden we niet het beste van beide werelden gebruiken, dus een VM schrijven om de games te implementeren (zoals nu dus besloten is), maar een USB bootloader gebruiken voor nieuwe VM versies en dergelijke erin te programmeren. Als je je PDA ofzo wil gebruiken is dat natuurlijk niet echt nodig, maar bij zo'n PIC of AVR is dat toch wel handig, zeker tijdens development.
Hetzelfde geldt voor alle andere apparaten, dus ook een makkelijke manier maken om nieuwe firmwares te flashen in de guns en alle losse apparaatjes.

[JanPaul123]

StefSybo schreef op dinsdag 20 maart 2007 @ 15:12:
[...]


Waarom zouden we niet het beste van beide werelden gebruiken, dus een VM schrijven om de games te implementeren (zoals nu dus besloten is), maar een USB bootloader gebruiken voor nieuwe VM versies en dergelijke erin te programmeren. Als je je PDA ofzo wil gebruiken is dat natuurlijk niet echt nodig, maar bij zo'n PIC of AVR is dat toch wel handig, zeker tijdens development.
Hetzelfde geldt voor alle andere apparaten, dus ook een makkelijke manier maken om nieuwe firmwares te flashen in de guns en alle losse apparaatjes.

Jep, dat was precies mijn idee.

EDIT: Iemand schreef op Talk:Virtual Machine:
"PS. is het trouwens niet handiger om deze wiki in het Engels voort te zetten? dan kan de rest van de wereld het ook lezen..."

Ben ik het wel mee eens...

[ Voor 13% gewijzigd door JanPaul123 op 20-03-2007 15:53 ]

[shorttracker]

Als het project uiteindelijk compleet is kan je denk ik beter alles in engels vertalen. Ik zou nu niet verder in het engels gaan... Sommige mensen begrijpen nu sommige dingen al niet, ga je verder in het engels wordt dit wel lastig.

Codes enzo kan je wel in het engels doen, maar ik denk dat je de wiki nog even nederlands moet houden...

[ Voor 52% gewijzigd door shorttracker op 20-03-2007 16:01 ]

[mithras]

shorttracker schreef op dinsdag 20 maart 2007 @ 15:58:
Als het project uiteindelijk compleet is kan je denk ik beter alles in engels vertalen. Ik zou nu niet verder in het engels gaan... Sommige mensen begrijpen nu sommige dingen al niet, ga je verder in het engels wordt dit wel lastig.

Codes enzo kan je wel in het engels doen, maar ik denk dat je de wiki nog even nederlands moet houden...

Precies: documenteer in Engels, presenteer in Engels, maar dit overleg wordt te ingewikkeld als het Engels wordt. Hier op GoT is Nederlands de taal die we schrijven, houd dat ook op de wiki zo. Dan kan je daarna je presentatie wel in het Engels doen (website e.d.).

[StefSybo]

mithras schreef op dinsdag 20 maart 2007 @ 16:04:
[...]
Precies: documenteer in Engels, presenteer in Engels, maar dit overleg wordt te ingewikkeld als het Engels wordt. Hier op GoT is Nederlands de taal die we schrijven, houd dat ook op de wiki zo. Dan kan je daarna je presentatie wel in het Engels doen (website e.d.).

Voor nu ben ik het daar wel mee eens, maar op den duur willen we natuurlijk een "echt" open source project worden en ik vind dat daar ook bij hoort dat iedereen dan moet kunnen helpen. Op den duur zal dus wel alles Engels moeten worden.

[Tp21]

StefSybo schreef op dinsdag 20 maart 2007 @ 16:07:
[...]


Voor nu ben ik het daar wel mee eens, maar op den duur willen we natuurlijk een "echt" open source project worden en ik vind dat daar ook bij hoort dat iedereen dan moet kunnen helpen. Op den duur zal dus wel alles Engels moeten worden.

op ten duur wel, maar op dit moment hebben we nog niet super veel te vertalen

[JanPaul123]

Tp21 schreef op dinsdag 20 maart 2007 @ 16:09:
[...]


op ten duur wel, maar op dit moment hebben we nog niet super veel te vertalen

Dat is juist mooi, nu hebben we nog niet zo veel om te vertalen. Als we nu de wiki Engels maken kunnen buitenlandse developers (en die zullen er zijn!) ook meedoen. Lijkt me wel fair en goed omdat er andere buitenlandse ervarener coders zijn.

[Scout77]

Gluggie schreef op dinsdag 20 maart 2007 @ 16:20: [...] Dat is juist mooi, nu hebben we nog niet zo veel om te vertalen. Als we nu de wiki Engels maken kunnen buitenlandse developers (en die zullen er zijn!) ook meedoen. Lijkt me wel fair en goed omdat er andere buitenlandse ervarener coders zijn.

Brainstormen zoals nu gebeurt om de grote lijnen uit te zetten is denk ik wel het makkelijkste in het Nederlands. Verdere gedetaileerde uitwerking is misschien wel beter direct in het Engels te doen.


Het is nu misschien wel makkelijker een aantal termen al wel in het Engels te gaan gebruiken. Anders moet je straks de hele wiki-layout met links enzo gaan omgooien.

Ik stel voor Wapons, Gun, Grenade, Flashbang, Time bomb, Health-kit, Ammo-kit, Utility-box, Base, en vast meer al te gaan gebruiken

Iemand nog een goede naam voor de spelleider? Master/main control is het net niet. Game Commander?

Is er een manier om in de Wiki makkelijk links te wijzigen voor alle pagina's ... zie nu al een puist werk namelijk

[ Voor 46% gewijzigd door Scout77 op 20-03-2007 16:38 ]

[Verwijderd]

Half engels / half nederlands is ook wel erg lastig, maar toch is het wel handig voor later. Als de developers maar programmeren in het Engels heb ik er verder geen problemen mee

[Tp21]

dan heb ik liever gelijk alles in het engels, lijkt me inderdaad ook makkelijker

[Verwijderd]

meteen een lijst met vertaalde woorden maken voor de mensen die het dan niet meer snappen en je bent klaar

[shorttracker]

Ik heb weer even een nieuwe stelling gemaakt in knopenhakken, denk dat dat het beste is...

[Verwijderd]

Even over de wiki: dit is echt nog geen Prototype hoor.. ver van.
Zoiets noemen ze een breadboard versie !!

[Phalox]

Eej oj! Gluggie wel in ere houden he! hij is begonnen met dit project, en heeft al veel gedaan.
Nu lijkt het wel of we zijn project aan het afpakken zijn.

offtopic:
Nog maar eens op wiki gaan kijke, dat wordt ook weer wat werk!

[Tp21]

Gluggie schreef op dinsdag 20 maart 2007 @ 13:50:
[...]


De officiele C18 compiler van Microchip zelf is ook wel goed, de Student Edition is gratis en het enige verschil is dat je niet alle optimalisaties kunt aanzetten. Ik heb zelf toegang tot de full version dus ik kan in principe de final builds daarmee compileren.

Wat betreft het Knopen Hakken, de consensus lijkt me gevormd wat betreft VM, dus vooruit. Wel stel ik voor de VM behoorlijk hoog te houden, dat wil zeggen dat we zo veel mogelijk in C implementeren en VM alles enkel aan elkaar knoopt om gameplay regels te vormen.

Zelf ben ik (dus) erg voor de PIC, niet alleen omdat Milestag en alles daar nu al geweldig mooi onder werkt door middel van interrupts, maar ook omdat het helemaal niet zo hoogdrempelig is als sommigen beweren. Het enige punt kan zijn het programmen, maar als je er eenmaal een bootloader op hebt zitten, kun je gewoon direct via USB je programma er inladen. Eventueel kan ik een heleboel PICs van een bootloader voorzien en rondsturen aan mensen die er graag een willen, zodat je alleen een USB kabeltje nodig hebt om 'em te proggen.

het zou heel handig zijn, indien we PIC's gaan gebruiken om ze met bootloader rond te sturen (zou ik in ieder geval heel fijn vinden), want op deze manier is het veel makkelijker om te beginnen met bouwen en programmeren, voor de extra onderdelen zou je eventueel goedkopere PIC's kunnen gebruiken (16f628A/16f648A, oid).

ohja, en ik had misschien nog wel een goed idee voor de VM, misschien een apart script voor de gun zelf, en een apart script voor de gametype, op deze manier kun je aparte guns aparte waardes geven (qua ammo, etc). en kun je de gametype scripts generiek houden, zodat die makkelijk overgepompt kunnen worden, en je toch meerdere verschillende guns kunt hebben.

[ Voor 10% gewijzigd door Tp21 op 20-03-2007 18:08 ]

[Sprite_tm]

TP21: Mja, dat zou kunnen... ware het niet dat een gun dan weer een stuk minder input/output heeft dan een compleet pak. Het lijkt me handiger om de gun dan wel instelbaar te laten maken dmv een aantal parameters: repeat rate, damage, cooldown period, dat soort zaken. Lijkt me het practischt om de mogelijke instellingen op een wiki-pagina op te sommen, dan kunnen we die in de gun-code zetten; mocht later blijken dat het er te veel zijn of dat vaste parameters toch uiteindelijk niet practisch blijkt, kunnen we altijd nog de VM ook in de guns implementeren.

Ik heb trouwens 2 nieuwe pagina's aangemaakt, VM/Design en VM/FragL. Mag ik de mensen die wat assembly-kennis (algemeen; proc die je kent boeit niet) hebben naar de eerste, en de mensen die kunnen programmeren in een hogere taal naar de tweede pagina verwijzen om de voorstellen aldaar te bekijken, te bediscussieren en uit te breiden? Dank

[Tp21]

ja, in eerste instantie is het waarschijnlijk beter om vaste parameters in de gun in te bouwen, het is niet zo flexibel, maar dat is voor latere zorg.
zolang het dan wel mogelijk is om met een optionele display de instelling te kunnen veranderen (eventueel met 'lock' zodat je in-game je instellingen niet kan veranderen).

[ Voor 36% gewijzigd door Tp21 op 20-03-2007 18:24 ]

[shorttracker]

Ik had in de wiki al een (redelijke) opsomming gemaakt dacht ik zo:
klikkk

Maar is het zowieso niet de bedoeling dat je jouw wapen stats vastlegd zijn in je gun? Vanuit je personal unit kan je dan nog commando's krijgen om je kogelschade, of iets in die richting (tijdelijk) te verhogen.

[Sprite_tm]

Is het trouwens niet een beter idee, om in the interest of balance, een aantal 'vaste' geweerprofielen te maken? Dus hetzij je geweer reload snel maar de kogels doen niet echt damage (machine gun), hetzij de kogels doen massive damage maar reloaden kost een halve eeuwigheid (shotgun), en zo nog meer uitgebalanceerde types? Ik denk dat dat uiteindelijk simpeler werkt dan iedereen z'n eigen parameters laten tweaken als het spel begint.

Shorttracker: Je haalt in die pagina een aantal modules door elkaar: imo is het geweer logisch gezien niet meer dan een unit met een trigger, evt een paar extra knoppen, en een IR-code-uitzend-dinges met lens e.d. erbij. Hoewel een LCD uiteindelijk wel in dezelfde behuizing gebouwd kan worden en zelfs in dezelfde proc afgehandeld kan worden, is het toch een compleet andere module. Verder heb ik nog wat op- en aanmerkingen, maar die zal ik wel op de talkpagina dumpen.

[ Voor 35% gewijzigd door Sprite_tm op 20-03-2007 18:33 ]

[Tp21]

zou ook mogelijk moeten zijn, maar dat kan later, eventueel in combinatie met een VM later in de gun.
maar eerst lijkt me losse instelbare dingen makkelijker (kun je ook een 'profiel' voor maken, alleen moet je dan met de hand alles invoeren, of overzenden).

[JanPaul123]

Sprite_tm schreef op dinsdag 20 maart 2007 @ 18:30:
Is het trouwens niet een beter idee, om in the interest of balance, een aantal 'vaste' geweerprofielen te maken? Dus hetzij je geweer reload snel maar de kogels doen niet echt damage (machine gun), hetzij de kogels doen massive damage maar reloaden kost een halve eeuwigheid (shotgun), en zo nog meer uitgebalanceerde types? Ik denk dat dat uiteindelijk simpeler werkt dan iedereen z'n eigen parameters laten tweaken als het spel begint.

Shorttracker: Je haalt in die pagina een aantal modules door elkaar: imo is het geweer logisch gezien niet meer dan een unit met een trigger, evt een paar extra knoppen, en een IR-code-uitzend-dinges met lens e.d. erbij. Hoewel een LCD uiteindelijk wel in dezelfde behuizing gebouwd kan worden en zelfs in dezelfde proc afgehandeld kan worden, is het toch een compleet andere module. Verder heb ik nog wat op- en aanmerkingen, maar die zal ik wel op de talkpagina dumpen.

Het lijkt mij wel wat dat je de guntypes opneemt in de VM. Al is het dan niet door middel van uitvoerbare code, maar gewoon als standaard parameters die aan het begin worden uitgelezen. We kunnen dan zoals je ook voorstelt een aantal standaardtypes maken, maar het lijkt me mooi als de eigenschappen van die typen wel te tweaken zijn. In FRAGL zou dat er dan zo uit kunnen zien:

#option MACHINEGUN 0
#option MACHINEGUN_FIREDELAY 100 // 100 ms
#option MACHINEGUN_ROUNDS 30 // 30 rounds in a clip
(...)
#option SHOTGUN 1
(...)

void main (void)
{
RESET_GUN = 1;
}


In die geest. Kan natuurlijk compleet andere uitwerking zijn in FRAGL. Zo'n option vertaalt zich dan letterlijk naar een soort semi-assembly, als een soort optie die geen machinecode is maar die de VM herkent als zijnde een optie voor firedelay, rounds, etc. Met het setten van register RESET_GUN leest de VM de 'type' van de gun uit (0 = machinegun, 1 = shotgun, bijv.) en stelt de gun dan in volgens de ingestelde waarden. Zo kost het weinig ruimte in FRAGL code (anders zou je helemaal een switch moeten maken die alle mogelijke types omvat) maar is het wel te tweaken. Is dit een idee of denk ik helemaal verkeerd?

[Sprite_tm]

Da's idd geen slecht idee. Ik zou het iets anders uitvoeren: dump de geweer-info gewoon 1-op-1 als losse data in de VM-code, en epibreer een instructie inelkaar die basically tegen de VM zegt: de info staat daar in het programmageheugen, leef je uit. Dan zou je daarna het selecteren van het type geweer wel aan de VM-code kunnen overlaten, maar de typen geweren vast kunnen zetten. In FragL zou het dan idd wel ongeveer hetzelfde werken, maar het is programmeertechnisch net iets netter.

Edit: Je moet die specs dan later nog wel vanuit de VM kunnen modden: op die manier zijn bijvoorbeeld power-ups die je firing rate of je damage verhogen, ook gewoon mogelijk.

[ Voor 15% gewijzigd door Sprite_tm op 20-03-2007 19:57 ]

[JanPaul123]

Sprite_tm schreef op dinsdag 20 maart 2007 @ 19:55:
Da's idd geen slecht idee. Ik zou het iets anders uitvoeren: dump de geweer-info gewoon 1-op-1 als losse data in de VM-code, en epibreer een instructie inelkaar die basically tegen de VM zegt: de info staat daar in het programmageheugen, leef je uit. Dan zou je daarna het selecteren van het type geweer wel aan de VM-code kunnen overlaten, maar de typen geweren vast kunnen zetten. In FragL zou het dan idd wel ongeveer hetzelfde werken, maar het is programmeertechnisch net iets netter.

Dat is misschien nog wel een beter idee ja.

Sprite_tm schreef op dinsdag 20 maart 2007 @ 19:55:
Edit: Je moet die specs dan later nog wel vanuit de VM kunnen modden: op die manier zijn bijvoorbeeld power-ups die je firing rate of je damage verhogen, ook gewoon mogelijk.

Uiteraard, zie ook onze voorstellen bij Interface met randapparatuur http://www.openlaserfrag....hp/Virtual_Machine/Design
Wat ik net bedenk als je die variabelen van geweren benadert als een register, dat je dan gewoon kunt zeggen van, vermenigvuldig aantal kogels keer 2 met één assembly instructie.

Maargoed, die VM is allemaal heel leuk en aardig (grom ), maar we moeten nu ook goed naar de hardware kijken. Anders hebben we straks niks waar we goed op kunnen testen.

1e vraag is PIC of AVR. Bij het Knopen Hakken lijkt het een gelijkstand... Ik ben dus voor de PIC, aangezien ik daar al voor geschreven heb voor dit systeem. En dat lijkt me toch wel een vrij zwaarwegend argument, Milestag doet het al perfect en programmeren in een peuleschil met de Bootloader. Enige echte nadeel is dat er niet zo'n goede gratis compiler bij is als de AVR, maar de C18 compiler is heel behoorlijk, zeker de nieuwe versie 3 is stukken beter dan de oude, en de Student Edition is prima, ik kan zelf altijd final versies compileren met de echte editie (meer optimalisaties dus neemt minder ruimte in).

Ik denk dat dit wel een heel belangrijk punt is waar we nu even uit moeten komen.

(Overigens ben ik over het algemeen niet zo voor stemming als bij Knopen Hakken gebeurt, ik denk dat onderbouwde discussie er aan vooraf moet gaan.

EDIT:
Hoewel, stemming is ook wel goed, als je maar alleen stemt met onderbouwde meningen.
Dus niet: Gluggie - Ik ben voor Engelse wiki.
Maar: Gluggie - Buitenlandse developers moeten de kans krijgen mee te werken en te denken.
)

[ Voor 11% gewijzigd door JanPaul123 op 20-03-2007 20:27 ]

[Sprite_tm]

Mmmm, het idee van Knopen Hakken was op zich dat er eerst een discussie is over hoe en wat en dan uiteindelijk, om de knoop door te hakken (duh), een stemming komt. Het probleem is nou eenmaal dat als je iedereen echt 100% op 1 lijn wilt hebben, je aan het discussieren blijft en het heeel veel moeite en tijd kost om misschien 1 of 2 mensen mee te krijgen. KnopenHakken is ook geen poll, maar dat lijkt wel begrepen te zijn; iedereen zet netjes naast z'n naam ook nog es een reden voor waarom 'ie zo stemt neer. Edit: Wat je er al bijeditte dus

Als je het niet erg vind ga ik het ontwikkelen van de VM op een PC (als simulator) en daarna een ATMega doen. Da's niet om de PIC-liefhebbers te testen, maar omdat ik daar toevallig net de beste tools voor heb liggen (ik draai bijvoorbeeld geen Windows, wat die C18-compiler al een stuk moeilijker bereikbaar maakt.) De bedoeling is wel dat de code zoveel mogelijk geabstraheerd ansi-compatible C word, wat betekent dat iedereen die het in een andere proc wil gooien, daar zo weinig mogelijk moeite voor hoeft te doen. Het voordeel daarvan is dat we meteen tegen eventuele platform-afhankelijke ongein aanlopen en weten we zeker dat we aan het eind niet met code zitten die slechts op 1 platform goed compileert. Dat betekent ook dat er een duidelijk gedefinieerde interface tussen de platform-afhankelijke code en de Vm-code zit; op die manier kan iemand zolang de VM nog ontwikkeld word, upgraden naar een nieuwe versie door simpelweg de nieuwe versie van de core te downloaden en in z'n eigen source-tree te zetten.

[JanPaul123]

Sprite_tm schreef op dinsdag 20 maart 2007 @ 20:34:
Als je het niet erg vind ga ik het ontwikkelen van de VM op een PC (als simulator) en daarna een ATMega doen. Da's niet om de PIC-liefhebbers te testen, maar omdat ik daar toevallig net de beste tools voor heb liggen (ik draai bijvoorbeeld geen Windows, wat die C18-compiler al een stuk moeilijker bereikbaar maakt.) De bedoeling is wel dat de code zoveel mogelijk geabstraheerd ansi-compatible C word, wat betekent dat iedereen die het in een andere proc wil gooien, daar zo weinig mogelijk moeite voor hoeft te doen. Het voordeel daarvan is dat we meteen tegen eventuele platform-afhankelijke ongein aanlopen en weten we zeker dat we aan het eind niet met code zitten die slechts op 1 platform goed compileert. Dat betekent ook dat er een duidelijk gedefinieerde interface tussen de platform-afhankelijke code en de Vm-code zit; op die manier kan iemand zolang de VM nog ontwikkeld word, upgraden naar een nieuwe versie door simpelweg de nieuwe versie van de core te downloaden en in z'n eigen source-tree te zetten.

Lijkt mij prima. Ik heb mijn code voor de PIC dus al zodanig abstract gemaakt dat het integreren van jouw VM niet moeilijk hoeft te worden. Wel denk ik dat de specs die op de wiki staan wat overrated zijn. 64K programmageheugen is bijvoorbeeld al meer dan de PIC die ik nu gebruik (die behoorlijk high-end is) en ook veel meer dan we nodig moeten hebben voor een vrij hoog geprogrammeerd programma. De dataruimte van 256 words zou ik willen opsplitsen in 128 words user-data en 128 words pre-defined registers, voor de interface met randapparatuur.

Geweldig trouwens, Sprite, dat jij de VM wil doen, ik zou daar niet aan willen beginnen.

Het lijkt me trouwens fair als we de knoop wat betreft de processor doorhakken en de PIC kiezen om nu mee te ontwikkelen aangezien vanuit een neutraal standpunt de consensus daarnaartoe neigt.

[ShadowLord]

Gluggie schreef op dinsdag 20 maart 2007 @ 20:16:
1e vraag is PIC of AVR. Bij het Knopen Hakken lijkt het een gelijkstand... Ik ben dus voor de PIC, aangezien ik daar al voor geschreven heb voor dit systeem. En dat lijkt me toch wel een vrij zwaarwegend argument, Milestag doet het al perfect en programmeren in een peuleschil met de Bootloader. Enige echte nadeel is dat er niet zo'n goede gratis compiler bij is als de AVR, maar de C18 compiler is heel behoorlijk, zeker de nieuwe versie 3 is stukken beter dan de oude, en de Student Edition is prima, ik kan zelf altijd final versies compileren met de echte editie (meer optimalisaties dus neemt minder ruimte in).

Als er geen vrije compiler is dan heeft het imho geen zin om het als basisplatform te gebruiken: niet al je devs kunnen er mee werken. Iedere dev moet een binary kunnen compilen. Anders ga je je echt veel te veel problemen op je hals halen.

Ik kan sowieso al geen (officieel) gebruik maken van de Student Edition, ik ben namelijk geen student. Dus dan zou ik eigenlijk al buitengesloten worden.

[EDIT] Even een reply op het bericht hierboven

Gluggie schreef op dinsdag 20 maart 2007 @ 20:47:
Lijkt mij prima. Ik heb mijn code voor de PIC dus al zodanig abstract gemaakt dat het integreren van jouw VM niet moeilijk hoeft te worden. Wel denk ik dat de specs die op de wiki staan wat overrated zijn. 64K programmageheugen is bijvoorbeeld al meer dan de PIC die ik nu gebruik (die behoorlijk high-end is) en ook veel meer dan we nodig moeten hebben voor een vrij hoog geprogrammeerd programma.

Ik ben het eens met het feit dat dit een beetje veel is. Aan de andere kant, we schrijven onze eigen VM dus het gebruik van een externe flash hiervoor is nog niet eens zo'n slecht idee. 64k geet een zeer comfortabele overhead.

De dataruimte van 256 words zou ik willen opsplitsen in 128 words user-data en 128 words pre-defined registers, voor de interface met randapparatuur.

128 words interface lijkt me wel erg veel eerlijk gezegd. 32 of 64 is beter denk ik.
Ik vind dat de VM trouwens ook 'native' bytes moet ondersteunen zodat een bewuste coder meer mogelijkheden heeft met het geheugen.

Het lijkt me trouwens fair als we de knoop wat betreft de processor doorhakken en de PIC kiezen om nu mee te ontwikkelen aangezien vanuit een neutraal standpunt de consensus daarnaartoe neigt.

Zie mijn bovenstaande comment aub.

[ Voor 38% gewijzigd door ShadowLord op 20-03-2007 20:56 ]

[Sprite_tm]

Mmm, het gebruiken van RAM-adressen voor I/O vind ik niet zo'n goed idee: je hoeft voor I/O-operaties eigenlijk alleen IN en OUT-instructies te ondersteunen, terwijl RAM eigenlijk alles ondersteund moet hebben; ik ben dus meer voor een aparte I/O-space. Die 64K kan idd wel teruggebracht worden naar bijvoorbeeld 4 of 8K. Bedenk ook: het programmageheugen hoeft niet fysiek in de uC te zitten maar mag er ook aangehangen worden door bijvoorbeeld een i2c-eeprommetje ofzo; we hebben zowiezo niet heel erg veel instructies/seconde nodig voor de VM.

ShaduwLord: Ik weet niet of je nou het RAM of de device interface te veel vind, maar ik vind beide meningen eng: als je ram bedoelt: in die 32 of 64 words moeten al je variabelen plus je stack opgeslagen worden. Da's best krap dan. Als je I/O bedoelt: We hebben het hier over 32/64 registers, niet randapparaten. Als je per randapparaat bijvoorbeeld een magere 8 registers pakt, zit je met sensoren, 2 geweren, een display en een RF-unit al vol. Omdat je verder alleen IN/OUT-instructies nodig hebt voor I/O, is het niet heel erg 'duur' om bijvoorbeeld 64K aan registers te gebruiken.

[ Voor 35% gewijzigd door Sprite_tm op 20-03-2007 21:01 ]

[ShadowLord]

Sprite_tm schreef op dinsdag 20 maart 2007 @ 20:57:
ShaduwLord: Ik weet niet of je nou het RAM of de device interface te veel vind, maar ik vind beide meningen eng: als je ram bedoelt: in die 32 of 64 words moeten al je variabelen plus je stack opgeslagen worden. Da's best krap dan. Als je I/O bedoelt: We hebben het hier over 32/64 registers, niet randapparaten. Als je per randapparaat bijvoorbeeld een magere 8 registers pakt, zit je met sensoren, 2 geweren, een display en een RF-unit al vol. Omdat je verder alleen IN/OUT-instructies nodig hebt voor I/O, is het niet heel erg 'duur' om bijvoorbeeld 64K aan registers te gebruiken.

Ik reageerde op het feit dat Gluggie de helft (256 bytes / 128 words) van het geheugen appart wou zetten voor IO, wat het beperkte geheugen van 512 bytes veel te ver afsnoept.
Editje: 'virtuele' adressen zoals jij voorsteld zijn dus veel beter.

Daarnaast had ik het over de mogelijkheid om 'native' met bytes te werken. In de Wiki wek je de impressie dat je alle vars 16 bits wil maken wat natuurlijk zonde van het geheugen is als je maar van 1 tot 100 wil tellen. Dus een mogelijkheid om bewust 8 bits getallen te alloceren zou ik niet gek vinden.

[ Voor 20% gewijzigd door ShadowLord op 20-03-2007 21:08 ]

[gerre22]

Ik loop al een heel stuk voor, ik weet het. Maar we willen hier een heel uitgebreid project maken. Met ondersteuning tot 100+ teams als ik het goed gelezen heb.
Ook lees ik dat sommigen het wel zien zitten om voor de teams verschillende kleurleds te gebruiken, dit lijkt met niet echt realistisch. I know ik loop wel wat voor, maar voor de mensen die de VM en toestanden in elkaar zetten lijkt het me makkelijk als die dat weten. Dan moet er geen sturing gemaakt worden voor dit onderdeel, wat wel een simplificatie geeft en een energiebesparing. Niet?

[Sprite_tm]

Gerre22: Nee hoor, dat valt later nog wel te abstraheren, en een enorme simplificatie geeft het eigenlijk niet.

[Stoney3K]

Eigenlijk heel opmerkelijk: We bouwen nu eigenlijk een kleine "Windows" kernel in een MCU. In Windows draaien alle applicaties ook in een VM, die als functie heeft om alle hardware onafhankelijk te maken, wat je dus bouwt is in feite een Hardware Abstraction Layer. Of het een werkelijke VM mag heten weet ik niet, maar het werkt en dat is het belangrijkste

[shorttracker]

Je bedoeld onze grote vriend Sprite zeker?
Die gozer loopt nu gewoon in zijn eentje een Virtual Machine in elkaar te proppen
Respect

[gerre22]

Jah, dat valt wel te abstraheren. Daar ga ik mee akkoord, de simplificatie kan ik totaal niet inschatten. Maar het lijkt me wel gewoon onrealistisch om 100+ verschillende kleuren derin te steken. Akkoord, het gaat om een teamnummer op de rug te zetten aan de hand van een soort led scherm op die plek.

Ik weet niet of ik het als lasertag moet zien als in de trend van superkleurrijk en iedereen vlamt daar maar rond in het bos of zaal. Of moet ik het zien als een wargame simulatie? Ik visualiseer me het graag. Ben zelf voorstander van de wargame simulatie, vandaar.

[shorttracker]

Ik denk dat het uiteindelijk gewoon een instelling wordt hoe je het wil spelen Het moet allebij kunnen...

[JanPaul123]

ShadowLord schreef op dinsdag 20 maart 2007 @ 20:51:
[...]
Als er geen vrije compiler is dan heeft het imho geen zin om het als basisplatform te gebruiken: niet al je devs kunnen er mee werken. Iedere dev moet een binary kunnen compilen. Anders ga je je echt veel te veel problemen op je hals halen.

Ik kan sowieso al geen (officieel) gebruik maken van de Student Edition, ik ben namelijk geen student. Dus dan zou ik eigenlijk al buitengesloten worden.

De C18 Student Edition is volgens mij gewoon voor iedereen te downloaden en te gebruiken, of je nou student bent of niet, volgens mij mag het gewoon. Lees de licentie er anders maar even op door.

[Borgoth]

Ik las net een stukje terug dat er moet worden ge promoot. Ik denk zelf dat we het beter binnen GoT kunnen houden tot we wat verder zijn. Als we nu al met 500 man er aan gaan werken bloed het deste sneller dood.
maar dat is mijn mening

[shorttracker]

Ik had trouwens nog een gewoon vraagje:

Wat gebeurt er op het moment dat de processor aan het herladen is, en er komt data binnen op de sensoren?? gaat hij dan verder met herladen, en pas als hij klaar is met herladen dan kan hij pas weer data ontvangen worden. Data die dus tijdens het herladen binnenkomt is gewoon verloren gegaan, of..?

[Sprite_tm]

Wat bedoel je met 'herladen'? uCs kunnen verder heel goed doen alsof ze 2 taken tegelijk aan het doen zijn hoor Worst case scenario moet de 'hit' even gebufferd worden en ziet de uC pas een milliseconde later dat er een hit is geweest.

[ Voor 78% gewijzigd door Sprite_tm op 21-03-2007 14:05 ]

[mithras]

shorttracker schreef op woensdag 21 maart 2007 @ 13:43:
Ik had trouwens nog een gewoon vraagje:

Wat gebeurt er op het moment dat de processor aan het herladen is, en er komt data binnen op de sensoren?? gaat hij dan verder met herladen, en pas als hij klaar is met herladen dan kan hij pas weer data ontvangen worden. Data die dus tijdens het herladen binnenkomt is gewoon verloren gegaan, of..?

Je kan toch ook op je pc een internet browser en een tekstverwerker open hebben staan Volgens mij worden die instructies door elkaar heen afgehandeld, zodat je geraakt kan worden terwijl je herlaadt

Dat brengt mij trouwens wel tot de volgende gedachte waar binnen de VM rekening mee moet worden gehouden: de gun moet niet alleen vertellen dat hij heeft geschoten, de centrale unit moet ook vertellen of de gun mag schieten of niet: denk aan bijvoorbeeld herladen. Je hebt dus bij de gun in twee richtingen verkeer

Sprite_tm schreef op woensdag 21 maart 2007 @ 14:04:
Wat bedoel je met 'herladen'?

Een geweer heeft een magazijn dat de kogels bevat. Herladen moet wanneer alle kogels in je magazijn op zijn. Omdat je kogels op zijn kan je dan niet meer schieten, dus moet het magazijn vervangen worden

[ Voor 15% gewijzigd door mithras op 21-03-2007 14:07 ]

[Verwijderd]

Lol.. droog hierboven

/edit: ff tussendoor trouwens... moet er wel een knoop doorgehakt worden op gebied van welke controller we gaan gebruiken? als we dan toch voor een VM gaan, kunnen we evengoed ieder zijn eigen voorkeurscontroller laten proggen, de principes blijven hetzelfde, ieder progt zijn eigen ding, de enige afspraken die we moeten maken is ivm de registers die gebruikt worden. Zo weten we ook ineens of ons ding nu wel degelijk cross-platform is.

Of zeg ik nu iets heel doms

[ Voor 90% gewijzigd door Verwijderd op 21-03-2007 15:41 ]