Open Source Lasergame/Laser Tag

[shorttracker]

Op je PC heet dat Multitasking toch?
DOS is gewoon single tasking... dus dat kan niet altijd

maargoed, met herladen bedoel ik inderdaad het herladen van ammo.
Zorgt de uC zelf voor het bufferen van het ingekomen signaal??

[Vuikie]

Dit ligt aan de uC/implementatie, als een hit binnen komt is dit denk ik het slimst af te werken als een interrupt. Dan handel je eerst de interrupt (data saven) af en daarna ga je gewoon verder met herladen (een hardware timer blijft gewoon lopen tijdens een interrupt) en als je hebt herladen werk je de rest van de interrupt af.

of je handelt eerst de complete interrupt af en dan ga je verder met herladen.

[Scout77]

Bij een ander systeem hebben ze ook classes van personeel.
http://www.laserrecon.com/ClassPage/CommanderClass.html (klik rechts voor andere klasse)

Helemaal handig lijkt me het niet aangezien ze daar ook de ammo en clip size aangeknoopt hebben maar het idee van meer health en een armour staan we wel aan.

Armour zit nu nog nergens in ... willen we daar nog iets mee doen?

[shorttracker]

Oeh, dat is inderdaad wel een vet idee...
Kogelsterkte enzo blijven dan hetzelfde, maar mischien kan je inderdad bepaalde personen meer armour geven, en snelere reload time(meer ervaren in het wisselen van clips)

[ Voor 6% gewijzigd door shorttracker op 21-03-2007 16:34 ]

[Scout77]

Of nog iets anders: Een ranking systeem met % voor leven, herlaad snelheid, enz. hankelijk van de scores die iemand in de voorgaande games heeft gehaald. Ik heb het dan even over versie veel later

[ Voor 13% gewijzigd door Scout77 op 21-03-2007 16:51 ]

[shorttracker]

haha, of zelfs zo erg, dat als je bijna dood bent, dat herladen erg lang duurt:P
maargoed, laten we eerst even het begin maken

[Scout77]

Maar ok dat zijn meer dingen voor later, alleen armour is dat iets waar we nu al dingen voor moeten weten omdat dat later mogelijk te kunnen laten zijn?

[JanPaul123]

Ik stel voor om de concrete specificaties van de elektronica nader te bekijken. Hier even wat vragen om over na te denken.

1) Microcontrollers.
Ik stel voor dat we nu gewoon de PIC gebruiken.

2) Personal unit.
PIC18F2550 als processor? Wat voor protocol voor modulair systeem (oftewel welke hardware ondersteunde functies kunnen we gebruiken?) Welke connectoren dan voor modulair systeem? Hoe LCD display en Sound aansluiten? Hoeveel knoppen?

3) Geweer
Microcontroller erin? Aansturing gebaseerd vanuit Personal Unit, of als zelfstandig systeem dat met Personal Unit informatie uitwisselt? Hoeveel knoppen? Batterij erin? LCD/geluid erin en zo ja hoe? Wat voor lampjes/toeters en bellen?

4) Sensoren
Microcontroller erin? RGB led of 1 kleur? IR led erbij voor eventuele leuke functies? TSOP's?

[deugtniet]

over armour, een heel simpele variant:

total damage=health+armour

je kan natuurlijk het ook iets realistischer maken:

damage done * armour value of unit= total damage
hier is een lagere armour waarde beter, maar moet >0

en dan kan je ook de armour uit laten werken door er een maximale schade aan te hangen.
ik ben niet goed in uitleggen, maar op verzoek zal ik het proberen

[shorttracker]

Ik zal wel even de pagina van het geweer veranden, dan kunnnen we daar weer stemen, enz...
ik ben trouwens ook voor een PIC,
sensoren geen uC toch? waarvoor?

[slopert]

Ik denk dat het belangrijker is om eerst vast te stellen wat voor hardware protocol er gebruikt gaat worden tussen rand apparatuur en de centrale cpu. De keuze van cpu is in weze niet zo belangrijk meer door het gebruik van een WM (volgens sprite_tm). Met mijn roestige informatie (mbo electronica meer dan tien jaar geleden) kan je met 1 rs232 maar communicatie opzetten tussen 2 controllers. Een I2C bus kan een soort ster netwerk opgebouwd worden en ruimte laten voor meerdere rand apparatuur.

[Scout77]

Gluggie schreef op woensdag 21 maart 2007 @ 17:58:
1) Microcontrollers.
Ik stel voor dat we nu gewoon de PIC gebruiken.
2) Personal unit.
PIC18F2550 als processor? Wat voor protocol voor modulair systeem (oftewel welke hardware ondersteunde functies kunnen we gebruiken?) Welke connectoren dan voor modulair systeem? Hoe LCD display en Sound aansluiten? Hoeveel knoppen?
3) Geweer
Microcontroller erin? Aansturing gebaseerd vanuit Personal Unit, of als zelfstandig systeem dat met Personal Unit informatie uitwisselt? Hoeveel knoppen? Batterij erin? LCD/geluid erin en zo ja hoe? Wat voor lampjes/toeters en bellen?
4) Sensoren
Microcontroller erin? RGB led of 1 kleur? IR led erbij voor eventuele leuke functies? TSOP's?

1) geen mening, ben in geen van allen thuis, is een zaak van de ontwikkelaars.
2) PU houdt alle zaken bij zoals health, ammo en armour. (zou ook geluid en lcd mogelijk maken op PU eventueel in een later stadium) http://openlaserfrag.org/wiki/index.php/Personal_Unit. Deze zo klein mogelijk houden (beetje in tegenspraak met ook geluid en lcd ... maar ok) met en kleine backup accu voor de tijden dat de gun wordt afgekoppeld tijdnes het spel.
3) Ik zou zeggen zelfstandig systeem dat info uitwisselt met centrale processor in PU, In het geweer alles wat je kan bedenken (geluid, lcd, accu, IR zender) deze is groter dan de PU en mag ook wel iets aan gewicht hebben. Ik ben tegenstander van het systeem dat de PU alles regelt zeker als je meerdere guns aan een PU wilt hangen lijkt me dat gewoon niet handig.
4) Sensoren, geen uC, alleen leds voor hits (ik ben tegenstander van team kleuren), IR ontvanger, bij milestag hadden ze eerst ook IR zenders bij sensoren maar hebben er niks mee gedaan en ze konden het ontvangst storen.

[shorttracker]

Over die batterij: Voor het geweer is het idd misschien slimmer om de accu in te bewaren, maar wat gebeurt er dan als je het geweer loskoppeld? dan krijgt de Personal Unit geen energie meer. En kan je dus helemaal niets meer.

Wat denk ik een mooie oplossing is: In de Personal Unit zit een kleine battery. En in het wapen zit een grote accu.
Zodra een wapen wordt ingeplugd dan kan de kleine battery van de Personal Unit worden opgeladen.

[Stoney3K]

Ik zou zelf die PU niet de ammo/munitie bij laten houden. In je gun zit toch al een uC die makkelijk dat soort zaken bij kan houden, of je gun nou kogels, plasma of een of andere laserbeam schiet maakt dan geen drol meer uit. Als je alle gun-logica in de PU zou stoppen, zou je de mogelijkheid kwijt raken om in het spel van wapen te wisselen (een andere gun heeft immers bv. ook een andere damage of andere ROF)

[Verwijderd]

IR zenders bij sensoren lijkt me ook overbodig, als je toch IR nog extra wil gebruiken kan je beter de gun IR module gebruiken (of eventueel nadien nog een aparte module bijmaken)

Pic is fine by me, absoluut geen ervaring met AVR dus jah

Zou zowieso controller in het wapen steken, kan je er veel leukere dingen mee doen en kan je idd nog altijd zelf beslissen of je bv een lcd op je wapen wil of op je pack (dmv de modulariteit)
/edit: zie wat Stoney zegt voor wat ik hiermee bedoel

Wat die leds betreft mja, het is toch wel handig om de kleuren te hebben als je ze wil gebruiken, je kan ze beter hebben en afzetten als je ze niet wil dan ze niet hebben en ze nodig hebben denk ik zo..

Qua kabels was ik zo even aan het denken, waarom geen USB connectoren? Twee voedingslijnen, twee lijnen die je als TX en RX kan misbruiken, makkelijk verkrijgbaar dus goedkoop... alleen geen vergrendeling op, tenzij er zo'n varianten bestaan natuurlijk.

MBT het protocol, asynchrone seriele overdracht kan je ook adressering mee doen, verschillende pics beschikken bv over een 9e bit waarmee je kan aangeven dat het om een adres gaat en niet om data.Zelfs als je dit niet hebt is het nog relatief eenvoudig in software af te handelen (bv 7 bits signaal en 8e bit bepaalt of het data of adres is) voordeel hiervan is de iets mindere gevoeligheid...
Als je een paar amperes gaat pulsen aan 40kHz kan je dat wel es gebruiken

[Stoney3K]

Gluggie schreef op woensdag 21 maart 2007 @ 17:58:
2) Personal unit.
PIC18F2550 als processor? Wat voor protocol voor modulair systeem (oftewel welke hardware ondersteunde functies kunnen we gebruiken?) Welke connectoren dan voor modulair systeem? Hoe LCD display en Sound aansluiten? Hoeveel knoppen?

3) Geweer
Microcontroller erin? Aansturing gebaseerd vanuit Personal Unit, of als zelfstandig systeem dat met Personal Unit informatie uitwisselt? Hoeveel knoppen? Batterij erin? LCD/geluid erin en zo ja hoe? Wat voor lampjes/toeters en bellen?

Voor de connecties tussen de "systemen" in stel ik voor om of I2C te gebruiken (maar dan heb je 4 pinnen nodig, 3 met een uitgeklede variant zonder power) of de UART-based structuur zoals Sprite hem voorstelde. De connectoren zou ik zelf redelijk stevig houden, ik heb zelf al XLR voorgesteld omdat daar ook makkelijk krulsnoeren (naar gun toe) aan te bevestigen zijn en je veel moeite moet doen om een XLR los te krijgen. Aan de gun-side zou ik dan wel een 1/4" jackplug maken, zodat er eventueel snel van gun gewisseld kan worden en het geheel toch losgaat als je met je kabel ergens achter zou blijven hangen.

Batterijen voor PU en gun zou ik apart houden. De gun heeft onderdelen die veel vermogen moeten leveren, de PU in principe niet. Die kan makkelijk van een viertal AA batterijen gevoed worden, terwijl je met de gun waarschijnlijk aan oplaadbare accupacks komt.

De sensoren hebben we in principe al, want het bestaande MilesTag ontwerp is goed getest en makkelijk te maken, en er hoeft verder niks bij. Ik ben zelf een tegenstander van teamkleuren-LED's, vooral als we wargame sims gaan spelen is dit niet bepaald realistisch. Mochten we ingame het nodig vinden om teams te kunnen onderscheiden kan dit ook via kleding of lintjes.

[Sprite_tm]

Hmm, ik ben wel voor ondersteuning voor LEDs; zeker als je wat meer lasergame-stijl een spel wilt doen (in 't donker dus) ipv meer een paintball-stijl zijn ze wel erg handig. Er hoeft verder niet veel moeite voor gedaan worden: gewoon de uC die de sensoren doet een paar extra pinnetjes geven en je bent klaar.

[shorttracker]

Ik ben ook zeker voor de LED's, als je in een mode zonder speeld kan je ze gewoon uitschakelen, of gewoon niet eens aansluiten. Ik vind wel dat je een mogelijkheid moet houden om ze aan te sluiten, wil je een keer met LED's spelen, meot dat gewoon mogenlijk zijn dacht ik zo...

[JanPaul123]

Scout77 schreef op woensdag 21 maart 2007 @ 18:51:
2) PU houdt alle zaken bij zoals health, ammo en armour. (zou ook geluid en lcd mogelijk maken op PU eventueel in een later stadium) http://openlaserfrag.org/wiki/index.php/Personal_Unit. Deze zo klein mogelijk houden (beetje in tegenspraak met ook geluid en lcd ... maar ok) met en kleine backup accu voor de tijden dat de gun wordt afgekoppeld tijdnes het spel.

shorttracker schreef op woensdag 21 maart 2007 @ 19:02:
Wat denk ik een mooie oplossing is: In de Personal Unit zit een kleine battery. En in het wapen zit een grote accu.
Zodra een wapen wordt ingeplugd dan kan de kleine battery van de Personal Unit worden opgeladen.

Lijkt mij ook een goed idee.

---

Scout77 schreef op woensdag 21 maart 2007 @ 18:51:
3) Ik zou zeggen zelfstandig systeem dat info uitwisselt met centrale processor in PU, In het geweer alles wat je kan bedenken (geluid, lcd, accu, IR zender) deze is groter dan de PU en mag ook wel iets aan gewicht hebben. Ik ben tegenstander van het systeem dat de PU alles regelt zeker als je meerdere guns aan een PU wilt hangen lijkt me dat gewoon niet handig.

Ja, zo stelde ik mij het ook voor. Ammo moet ook onthouden worden als je geweer loskoppelt en dergelijk, dus dan moet je daar sowieso iets in hebben. En je kunt gewoon veel leukere dingen doen met het geweer als daar een uC in zit. En een LCD in het geweer is ook heel handig, Health en dergelijke kan er ook op als de Personal Unit dat doorgeeft.

---

shorttracker schreef op woensdag 21 maart 2007 @ 18:17:
sensoren geen uC toch? waarvoor?

Mwa, kan handig zijn om te identificeren WAAR je geraakt bent, dat gaat niet als je alle sensoren achter elkaar plant. Maar lijkt mij ook niet zo heel nuttig nee.

---

Sprite_tm schreef op woensdag 21 maart 2007 @ 19:22:
Hmm, ik ben wel voor ondersteuning voor LEDs; zeker als je wat meer lasergame-stijl een spel wilt doen (in 't donker dus) ipv meer een paintball-stijl zijn ze wel erg handig. Er hoeft verder niet veel moeite voor gedaan worden: gewoon de uC die de sensoren doet een paar extra pinnetjes geven en je bent klaar.

shorttracker schreef op woensdag 21 maart 2007 @ 19:26:
Ik ben ook zeker voor de LED's, als je in een mode zonder speeld kan je ze gewoon uitschakelen, of gewoon niet eens aansluiten. Ik vind wel dat je een mogelijkheid moet houden om ze aan te sluiten, wil je een keer met LED's spelen, meot dat gewoon mogenlijk zijn dacht ik zo...

Can't agree more. Het moet een optie zijn. Voor wargame-sim kun je het uitzetten. En het maakt ook leuke spelvarianten mogelijk (Zoals Take'm over, leuk idee, wie heeft die bedacht?)

---

Verwijderd schreef op woensdag 21 maart 2007 @ 19:07:
IR zenders bij sensoren lijkt me ook overbodig, als je toch IR nog extra wil gebruiken kan je beter de gun IR module gebruiken (of eventueel nadien nog een aparte module bijmaken)

Mja, je zou IR ledjes in sensoren kunnen inbouwen om van spelers een soort baken te maken die IR signalen in alle kanten zendt (als hij bijvoorbeeld radioactief is ofzo.)

Scout77 schreef op woensdag 21 maart 2007 @ 18:51:
IR ontvanger, bij milestag hadden ze eerst ook IR zenders bij sensoren maar hebben er niks mee gedaan en ze konden het ontvangst storen.

Dat kwam omdat de IR leds aangingen tegelijk met de gewone led, maar dat hoeven wij natuurlijk niet zo te doen!

---

Verwijderd schreef op woensdag 21 maart 2007 @ 19:07:
Qua kabels was ik zo even aan het denken, waarom geen USB connectoren? Twee voedingslijnen, twee lijnen die je als TX en RX kan misbruiken, makkelijk verkrijgbaar dus goedkoop... alleen geen vergrendeling op, tenzij er zo'n varianten bestaan natuurlijk..

Daar zat ik inderdaad ook al aan te denken. Geen vergrendeling inderaad, maar je moet je geweer ook niet loslaten natuurlijk, en misschien zelfs een voordeel want als de draad ergens achter blijft haken schiet hij gewoon los en gaat hij niet kapot.

[Phalox]

Een uc in sensors -> handig voor statistieken.. het is altijd mooi om te zien waar je het meest geraakt bent. zo kan je onderscheid maken tussen headshot en chestshots

[shorttracker]

Weet iemand trouwens hoe breed die straal is uit het geweer??
Ik hoop niet dat deze heel erg breed wordt, of zo breed wordt als de lens...
in het eerste geval kan je zo meerdere mensen raken, in het tweede geval moet je wel precies op de sensor mikken wil je raken...
(en ja ik weet dat als de bundel divigerend is dat verschilt per meter )

[Verwijderd]

Breedte van de straal kan volgens mij best afhankelijk zijn van het type gun. Een shotgun bv een breed divergerende straal, zodat je een kort bereik hebt maar van dichtbij "enorme ravage" kan aanrichten, terwijl een sniper een enorm fijne bundel zou moeten hebben.

[mkleinman]

Ola.

Ik heb jaren gewerkt met een commercieel systeem ( Laserquest ) en heb daar ook jarenlang het onderhoud op gedaan.

Als iemand nog hulp nodig heb :-).

*BOOKMARKED*

[ Voor 4% gewijzigd door mkleinman op 21-03-2007 20:21 ]

[Scout77]

tokesnugerd schreef op woensdag 21 maart 2007 @ 20:03:
Een uc in sensors -> handig voor statistieken.. het is altijd mooi om te zien waar je het meest geraakt bent. zo kan je onderscheid maken tussen headshot en chestshots

Ooit heb ik er laserforums een discussie over gelezen, volgens mij hebben ze toen ook het nodige geprobeerd maar omdat je hoofdsensor misschien een 50cm van je borst of rug sensor zit was het verschil erg moeilijk waar te nemen. Maar het topic vinden op laserforums is me helaas niet gelukt.

Kan dat onderscheid trouwens niet gemaakt worden zonder dat er een uc in de sensor moet zitten?

Uit een discussie op de http://openlaserfrag.org/wiki/index.php/Talk:Geweer pagina. Had ik al een opmerking gemaakt over de ammo, gun en PU
(Ik stel me de PU voor als een rugzakje met daarin: health, ammo en armour. Plus bijhouden spel stats.)
"Het makkelijkste lijkt mij dat je bij een reload een clip doorgeeft van de PU naar de gun en ben je hem kwijt als je de gun afkoppelt, 8< 8<. De gun houdt zelf bij hoeveel kogels hij nog heeft en weet dan zelf wanneer hij leeg is."
Als je dus een gun afkoppelt heeft hij dus nog de laatste clip in zijn "geheugen" zitten, en als iemand anders hem dan aankoppelt kan eerst met de oude ammo worden geschoten.
Als er dan toch een uC inzit zou ik die ook de geluiden laten regelen. en een gedeelte van de aansturing van het LCD.


*bedenkt me net, hoe mooi zou het zijn als je iemand anders een deel van je ammo kunt geven. Health is niet echt logisch maar ammo zou toch best moetten kunnen.

[ Voor 41% gewijzigd door Scout77 op 21-03-2007 20:56 ]

[Scout77]

Kunnen we gewoon niet met echte geweren gaan schieten ... veel makkelijker en zijn we veel sneller klaar

[JanPaul123]

Scout77 schreef op woensdag 21 maart 2007 @ 20:45:
[...]

Ooit heb ik er laserforums een discussie over gelezen, volgens mij hebben ze toen ook het nodige geprobeerd maar omdat je hoofdsensor misschien een 50cm van je borst of rug sensor zit was het verschil erg moeilijk waar te nemen. Maar het topic vinden op laserforums is me helaas niet gelukt.

Kan dat onderscheid trouwens niet gemaakt worden zonder dat er een uc in de sensor moet zitten?

Nee, want dan zou je
a. Voor elke sensor een apart lijntje moeten hebben lopen, dat is veel te veel.
b. Wordt dan het verwerken niet te doen aangezien je alle lijntjes apart moet bijhouden, en dit kan dan ook veel minder goed met interrupts.

Dus dat is praktisch onmogelijk.

[shorttracker]

dat kan ook gedaan worden met system messages
is al een optie voor in het protocol.
Is het alleen nog een kwestie dat de personal unit die code via het geweer de lucht in kan krijgen

[Stoney3K]

Scout77 schreef op woensdag 21 maart 2007 @ 20:45:
[...]
Uit een discussie op de http://openlaserfrag.org/wiki/index.php/Talk:Geweer pagina. Had ik al een opmerking gemaakt over de ammo, gun en PU
(Ik stel me de PU voor als een rugzakje met daarin: health, ammo en armour. Plus bijhouden spel stats.)
"Het makkelijkste lijkt mij dat je bij een reload een clip doorgeeft van de PU naar de gun en ben je hem kwijt als je de gun afkoppelt, 8< 8<. De gun houdt zelf bij hoeveel kogels hij nog heeft en weet dan zelf wanneer hij leeg is."
Als je dus een gun afkoppelt heeft hij dus nog de laatste clip in zijn "geheugen" zitten, en als iemand anders hem dan aankoppelt kan eerst met de oude ammo worden geschoten.
Als er dan toch een uC inzit zou ik die ook de geluiden laten regelen. en een gedeelte van de aansturing van het LCD.

*bedenkt me net, hoe mooi zou het zijn als je iemand anders een deel van je ammo kunt geven. Health is niet echt logisch maar ammo zou toch best moetten kunnen.

Daar had ik al een ander idee voor, gebruik voor je ammo fysieke magazijnen met een EPROM chip erin die contact maken als je ze erin stopt. Geen magazijn -> gun schiet niet. Per schot wordt het EPROMmetje geupdate met de hoeveelheid kogels die er nog op staan. Leeg is leeg en kan alleen gereset worden bij een ammo point of iets dergelijks... je moet dan dus fysiek magazijnen mee gaan nemen (en niet knopje=reload) en die kun je dan dus ook makkelijk van een uitgeschakelde speler looten of aan iemand anders geven.

[JanPaul123]

Stoney3K schreef op woensdag 21 maart 2007 @ 21:06:
[...]


Daar had ik al een ander idee voor, gebruik voor je ammo fysieke magazijnen met een EPROM chip erin die contact maken als je ze erin stopt. Geen magazijn -> gun schiet niet. Per schot wordt het EPROMmetje geupdate met de hoeveelheid kogels die er nog op staan. Leeg is leeg en kan alleen gereset worden bij een ammo point of iets dergelijks... je moet dan dus fysiek magazijnen mee gaan nemen (en niet knopje=reload) en die kun je dan dus ook makkelijk van een uitgeschakelde speler looten of aan iemand anders geven.

Dit is inderdaad wel een goed idee, maar moet mijns inziens wel als OPTIE mogelijk zijn. We moeten dus wel een reload knop monteren voor mensen die minder van war-sim mode houden. Er kan dan worden ingesteld of herladen via het knopje gaat of alleen op die manier moet.

Ik heb ook de homepage van OpenLaserFrag.org wat versierd.

[shorttracker]

Ehm, dat gaat denk ik wel ERG ver...
Dan moet je een goed kliksysteem gaan maken, enz.
Bovendien: hoe wil je dat gaan doen met verschillende wapens, en wapens zoals een bazooka???

Ik denk niet dat het erg slim is om het zo realistisch te maken....

[Stoney3K]

shorttracker schreef op woensdag 21 maart 2007 @ 21:15:
Ehm, dat gaat denk ik wel ERG ver...
Dan moet je een goed kliksysteem gaan maken, enz.
Bovendien: hoe wil je dat gaan doen met verschillende wapens, en wapens zoals een bazooka???

Ik denk niet dat het erg slim is om het zo realistisch te maken....

Ik ben het met Gluggie eens dat het een optie moet zijn. Ik ben zelf echt meer van de war-sim kant, en wil graag 'as real as it gets' spelen. In een echt wapen kun je ook niet zomaar munitie van een ander wapen proppen.

[JanPaul123]

shorttracker schreef op woensdag 21 maart 2007 @ 21:15:
Ehm, dat gaat denk ik wel ERG ver...
Dan moet je een goed kliksysteem gaan maken, enz.
Bovendien: hoe wil je dat gaan doen met verschillende wapens, en wapens zoals een bazooka???

Ik denk niet dat het erg slim is om het zo realistisch te maken....

Valt wel mee denk ik, we maken het toch al modulair, dus gewoon een USB poort aan de onderkant van het geweer waar het magazijn in moet, en dan het magazijn erin steken alsof het een soort USB stick is. Ik vind dat we in ieder geval de optie moeten overwegen voor war-sim fans.

[Stoney3K]

Gluggie schreef op woensdag 21 maart 2007 @ 21:20:
[...]


Valt wel mee denk ik, we maken het toch al modulair, dus gewoon een USB poort aan de onderkant van het geweer waar het magazijn in moet, en dan het magazijn erin steken alsof het een soort USB stick is. Ik vind dat we in ieder geval de optie moeten overwegen voor war-sim fans.

Thinking about that, er zijn toch USB-stick / SD kaart / whatever adapters die je zo aan een uC kan prikken? Dan zouden we daar al weinig gezeur mee hebben. En natuurlijk kun je altijd in de software instellen dat de inhoud van het magazijn simpelweg ignored mag worden.

[shorttracker]

ohke, jullie hebben me (verdomd snel) overgehaald...
vooral die usb, en dat het een optie moet zijn...

Ik moet toegeven, het is natuurlijk wel super vet
ik hoop dat het ook een beetje uitvoerbaar is.

[Phalox]

Haha eventjes je usb stick in je geweer knallen. EEPROM zou ik nu niet direct dien.. die dingen zijn gemaakt om te LEZEN, veel minder om te schrijven. usb stick is goedkoop, en met een 64 MB versie kom je al meeeeeeer dan toe (kost je nog 5 euro)
Begint hier wel mooi te worden, wie is er nu eigenlijk bezig aan de basis ? agh, ik wou dat ik kom meehelpen, dan klonk die vraag niet zo cru !

[shorttracker]

Verschil is dat een EEPROM een heeel stuk goedkoper is. De goedkoopste sd kaart die ik heb kunnen vinden was €4.00, en een USB stick kwam ik rond de €5.00.

De goedkoopste EEPROM is daarintegen €0.54 klik ook al gaan die eeproms minder lang mee, ze kunnen wel 9x kapotgaan en dan zijn ze net zo duur als een usb stick..
nog een plugje erbij en je bent klaar...

(een ander voorbeeld):
heb je 10 clips, dan kost dat €50,- aan USB sticks..
dat kost 20€ aan EEPROMS (de eeprom + plugje + printje + bescherming eromheen + ??)

[ Voor 0% gewijzigd door shorttracker op 21-03-2007 23:41 . Reden: link ff werkend gemaakt ]

[Verwijderd]

Eh ne, het verschil is, in een usb stick zit een eeprom met usb interface, veel plezier om die te schrijven of uit te lezen


kan je trouwens niet gewoon met een weerstandsbrugje werken voor zo'n reload.. gewoon drie pinnetjes, via ADC spanning uitlezen en adh daarvan weet je hoeveel rounds je bijgeladen hebt?
Mr ja dan kan je je clip natuurlijk wel zogenaamd "oneindig" gebruiken. Mss dmv condensator die altijd tot een bep waarde ontladen word.. hmz, toch maar eeprommetje dan

/edit: ik wou dus zeggen, een usb stick heeft net dezelfde eeprom als een gewone chip, maar de controller in de stick gaat de data een soort van at random plaatsen zodat elke cel ongeveer evenveel gebruikt wordt, om de levensduur hoger te maken.

[ Voor 20% gewijzigd door Verwijderd op 21-03-2007 23:35 ]

[Scout77]

Het systeem van usb-stick ben ik toch geen voorstander van, kosten, want je hebt er een aantal voor nodig, nu heb ik ook nog wel wat oudjes liggen ... maar toch.
Hoe ga je die dingen weer opladen, moet je ze weer ergens anders in steken en welke is dan leeg en welke niet. Even iemand anders z'n ammo jatten, dan moet iedereen hetzelfde soort slot hebben.

Is iets voor een latere latere versie misschien ...

Lijkt me het handigste eerst de ammo gewoon in de PU te houden.

[ Voor 7% gewijzigd door Scout77 op 22-03-2007 00:40 ]

[Sprite_tm]

We kunnen er allicht een optie van maken; we nemen wel een methode op om eventuele extra ammo in een geweer of clip uit te lezen / weg te schrijven, maar of het geweer dat ook daadwerkelijk implementeert, is optioneel. Vanuit de VM kan er dan gebruik van gemaakt worden als een spel dat vereist, of de ammohoeveelheid gewoon zelf bijgehouden worden als het spel het niet vereist of als het niet nodig is voor een bepaald speltype.

[Stoney3K]

Sprite_tm schreef op donderdag 22 maart 2007 @ 08:41:
We kunnen er allicht een optie van maken; we nemen wel een methode op om eventuele extra ammo in een geweer of clip uit te lezen / weg te schrijven, maar of het geweer dat ook daadwerkelijk implementeert, is optioneel. Vanuit de VM kan er dan gebruik van gemaakt worden als een spel dat vereist, of de ammohoeveelheid gewoon zelf bijgehouden worden als het spel het niet vereist of als het niet nodig is voor een bepaald speltype.

Wat mijn voorstel was is om de PU alleen maar de guns te vertellen of ze mogen schieten. Het werkelijke afhandelen van al het schietgebeuren gebeurt door de controllers in de guns zelf, als een speler 'dood' is dan gaat er van de PU een bericht uit, wat de guns op non-actief stelt en op de sensors (eventueel in een aparte controller) de hit lights gaan branden. Het voordeel is dat dit ontzettend schaalbaar is en ook bruikbaar voor andere items/rollen (medic, engineer), de PU handelt dus alleen de werkelijke spelregels af, wat het implementeren van de VM nog eens een stuk makkelijker maakt.

[JanPaul123]

Stoney3K schreef op donderdag 22 maart 2007 @ 14:27:
[...]


Wat mijn voorstel was is om de PU alleen maar de guns te vertellen of ze mogen schieten. Het werkelijke afhandelen van al het schietgebeuren gebeurt door de controllers in de guns zelf, als een speler 'dood' is dan gaat er van de PU een bericht uit, wat de guns op non-actief stelt en op de sensors (eventueel in een aparte controller) de hit lights gaan branden. Het voordeel is dat dit ontzettend schaalbaar is en ook bruikbaar voor andere items/rollen (medic, engineer), de PU handelt dus alleen de werkelijke spelregels af, wat het implementeren van de VM nog eens een stuk makkelijker maakt.

Ja, volgens mij denken de meesten er zo over. Ik denk ook dat dit het handigste is.

[Scout77]

Helemaal voor

[Verwijderd]

Stoney3K schreef op donderdag 22 maart 2007 @ 14:27:
[...]
Het voordeel is dat dit ontzettend schaalbaar is en ook bruikbaar voor andere items/rollen (medic, engineer), de PU handelt dus alleen de werkelijke spelregels af, wat het implementeren van de VM nog eens een stuk makkelijker maakt.

Is het dan niet zo dat het geweer ook een VM nodig heeft? dan krijg je dus een generic VM met daar bovenop de code om te schieten (bij het geweer) of met de spelregels (PU)

(of is dit precies wat je bedoeld?)

[Verwijderd]

Lijkt me niet nodig... denk dat je de gun eerder als een "plug-in module" kan bekijken, net zoals alle andere ideeen die al zijn bovengekomtbovengekomen. Zolang ieder "zijn" microcontroller met dezelfde registers programmeert zodat de gun compatible is met de VM in het pack heb je geen twee VM's nodig.

[ Voor 3% gewijzigd door Verwijderd op 22-03-2007 16:57 . Reden: bovengekomt??? wtf?? :+ ]

[JanPaul123]

Verwijderd schreef op donderdag 22 maart 2007 @ 15:16:
[...]
Is het dan niet zo dat het geweer ook een VM nodig heeft? dan krijg je dus een generic VM met daar bovenop de code om te schieten (bij het geweer) of met de spelregels (PU)

(of is dit precies wat je bedoeld?)

Nee, het lijkt me handiger dat je de gun gewoon kunt instellen via de normale VM, wat scudracer dus ook zegt.

[ Voor 3% gewijzigd door JanPaul123 op 22-03-2007 15:32 ]

[GeertJohan]

Microsoft had het fout!!
The WOW starts NOW!!!

Ik heb zojuist dit topic een beetje zitten doorlezen en ben zeer geintereseerd.

mij lijkt het leuk om te helpen aan de programeer kant.
wel met JAVA en (erg) veel met PHP.
ik weet dus wel hoe te programeren!!

ik heb zelf alleen nog geen (praktijk) ervaring met PIC/microcontroller's, is dat nodig??

edit:
owjah, ik heb veel tijd!

[ Voor 23% gewijzigd door GeertJohan op 22-03-2007 18:05 ]

[Tp21]

ja, is het niet handig om een computer deel aan dit geheel te hangen? om bijvoorbeeld statistics door te zenden, om een PIC te update kan je toch al USB gebruiken, is het mogelijk om diezelfde USB-poort voor 'normale' data te gebruiken?

[Sprite_tm]

Daar kan je fijn IR voor misbruiken. Dat gebruik je aan het begin toch al om je settings + spelregels up te loaden naar de PU, later kan het er ook wel weer afgehaald worden dmv op een computer te schieten met een bepaalde kogel

[Phalox]

Ach, die usb/serieel kan je later nog altijd toevoegen. ik denk niet dat dat het probleem zal zijn. Als dat er nu niet in zit, kan het later nog altijd.

[Janoz]

Ik lurk af en toe door dit topic omdat ik het wel een interessant project vind. (Eens kijken of het het initiele enthousiasme overleefd). Ik weet niet of men al uit is over het VM gebeuren, maar een bijkomend voordeel van een VM is dat je los van architectuur/hardware kunt ontwikkelen. Dat is natuurlijk al vaker vermeld, maar volgens mij is nog niet vermeld dat het niet perse hardware hoeft te wezen. Je kunt ook keurig die VM implementeren in bv unreal, quake of source (hl2). Lijkt me een ideale simpele methode om je game te kunnen playtesten met wat vrienden zonder dat je de pakken tevoorschijn hoeft te halen en/of een ruimte of locatie moet regelen/vinden.

Valt het op dat ik meer een software iemand ben

[ Voor 4% gewijzigd door Janoz op 22-03-2007 17:09 ]

[Stoney3K]

Sprite_tm schreef op donderdag 22 maart 2007 @ 16:56:
Daar kan je fijn IR voor misbruiken. Dat gebruik je aan het begin toch al om je settings + spelregels up te loaden naar de PU, later kan het er ook wel weer afgehaald worden dmv op een computer te schieten met een bepaalde kogel

Je kan ook kijken of je gewoon een IrDA poort op je PU kunt maken. Zijn zat IC's die een UART aan de ene kant willen en een IrDA transceiver aan de andere kant, dat zou ideaal zijn om tussen PU/gun/PC/enz korte communicatie uit te wisselen.

[JanPaul123]

tokesnugerd schreef op donderdag 22 maart 2007 @ 17:03:
Ach, die usb/serieel kan je later nog altijd toevoegen. ik denk niet dat dat het probleem zal zijn. Als dat er nu niet in zit, kan het later nog altijd.

Mja, USB werkt al met de bootloader...

[JanPaul123]

GJR - Squarc schreef op donderdag 22 maart 2007 @ 16:00:
Microsoft had het fout!!
The WOW starts NOW!!!

Ik heb zojuist dit topic een beetje zitten doorlezen en ben zeer geintereseerd.

mij lijkt het leuk om te helpen aan de programeer kant.
wel met JAVA en (erg) veel met PHP.
ik weet dus wel hoe te programeren!!

ik heb zelf alleen nog geen (praktijk) ervaring met PIC/microcontroller's, is dat nodig??

edit:
owjah, ik heb veel tijd!

Super! Zap door naar www.openlaserfrag.org en meld je aan op de wiki zou ik zeggen.

[GeertJohan]

Gluggie schreef op donderdag 22 maart 2007 @ 18:57:
[...]


Super! Zap door naar www.openlaserfrag.org en meld je aan op de wiki zou ik zeggen.

al gedaan thanks!

[slopert]

Sprite en gluggie, hadden jullie al iets in gedachte hoe de verschillende onderdelen qua hardware aan elkaar 'geplakt' moeten worden. UART, I2C of misschien iets anders?
Of is dat op dit moment niet belangrijk? Ik heb alleen wat custom analoge electronica gemaakt voor klanten. Die kwamen met een spec en daar bouwde ik mijn schakeling om/op. Ik denk dat het met een project van deze (beoogde) grote nodig is om een aantal specs te stellen en daarbij het software model te maken en daarna pas de specifieke (electrische) onderdelen te zoeken die voldoen aan de software specs.

[edit] Daarbij bedoel ik dus wel dat bij de software spec al duidelijk moet zijn hoe de stukken hardware aan elkaar geknoopt moeten worden.

[ Voor 11% gewijzigd door slopert op 22-03-2007 21:57 ]

[JanPaul123]

slopert schreef op donderdag 22 maart 2007 @ 20:30:
Sprite en gluggie, hadden jullie al iets in gedachte hoe de verschillende onderdelen qua hardware aan elkaar 'geplakt' moeten worden. UART, I2C of misschien iets anders?
Of is dat op dit moment niet belangrijk? Ik heb alleen wat custom analoge electronica gemaakt voor klanten. Die kwamen met een spec en daar bouwde ik mijn schakeling om/op. Ik denk dat het met een project van deze (beoogde) grote nodig is om een aantal specs te stellen en daarbij het software model te maken en daarna pas de specifieke (electrische) onderdelen te zoeken die voldoen aan de software specs.

[edit] Daarbij bedoel ik dus wel dat bij de software spec al duidelijk moet zijn hoe de stukken hardware aan elkaar geknoopt moeten worden.

Uiteraard, daar denken we al druk over na. Ik weet zelf nog niet wat het beste is, ik overleg dit weekend met mensen die daar meer verstand van hebben.

[Gnuitenjong]

Ik vind het ook een erg gaaf idee en zou waar mogelijk ook wel willen meehelpen; lijkt me wel erg gaaf om (in een later stadium?) de wapens te maken, of in bestaande speelgoedwapens te bouwen o.i.d., dus meer het esthetische aspect. Verder kan ik vrij goed solderen, heb wel wat elektronica-kennis etc.
Ik hoor het wel

[slopert]

Je kan je ook aanmelden op http://openlaserfrag.org/wiki/index.php/Medewerkers voor ieder gedeelte van het project zijn mensen welkom.

[GeertJohan]

@Sprite: Sprite heb je mn mailtje ontvangen?? daarin de uitleg \/


@De rest: binnenkort zal het eerste plan online komen waarin precies staat hoe de opbouw zal verlopen en wat de doelstellingen zijn. ook zal er binnenkort bekend worden hoe de VM gaat werken en hoe FragL verder gaat. Dit alles natuurlijk 'to be edited' en als voorstel.

[Verwijderd]

Wat is nou dan het preciese doel van dit project? Dat er uiteindelijk kant en klare bouwtekeningen, ontwerpen en software komt voor iedereen om zijn eigen gun/pak te maken? Of misschien zelfs een soort inkoopactie van alle benodigde elektronica?

[Scout77]

Verwijderd schreef op donderdag 22 maart 2007 @ 23:33:
Wat is nou dan het preciese doel van dit project? Dat er uiteindelijk kant en klare bouwtekeningen, ontwerpen en software komt voor iedereen om zijn eigen gun/pak te maken? Of misschien zelfs een soort inkoopactie van alle benodigde elektronica?

Zeker de ontwerpen en software, daarom ook opensource
Dat laatste is misschien ook wel een goed idee, maar daarvoor dient eerst de rest er te zijn.

[GeertJohan]

Scout77 schreef op vrijdag 23 maart 2007 @ 00:35:
[...]


Zeker de ontwerpen en software, daarom ook opensource
Dat laatste is misschien ook wel een goed idee, maar daarvoor dient eerst de rest er te zijn.

Het uiteindelijke doel is dat onze vorm van lasergamen kan worden gebruikt overal in nederland, een universeel systeem waarbij het speltype snel kan worden veranderd door een simpele update. heb je eenmaal een pak gemaakt/gekocht?? Dan kun je met iedereen die ditzelfde systeem bezit lasergamen waar je maar wilt.

[Verwijderd]

GJR - Squarc schreef op vrijdag 23 maart 2007 @ 09:15:
[...]


Het uiteindelijke doel is dat onze vorm van lasergamen kan worden gebruikt overal in nederland,

Belgie is ook aanwezig hoor

Ik ben wel even een weekje in het buitenland voor het werk dus kan ik maar zeer zelden dit snel groeiend topic in het oog houden.

[GeertJohan]

Verwijderd schreef op vrijdag 23 maart 2007 @ 09:50:
[...]


Belgie is ook aanwezig hoor

Ik ben wel even een weekje in het buitenland voor het werk dus kan ik maar zeer zelden dit snel groeiend topic in het oog houden.

Welkom belgie!!

mja, in belgie hebben ze tog airsoft?? ipv lasergamen

[ Voor 8% gewijzigd door GeertJohan op 23-03-2007 14:07 ]

[shorttracker]

airsoft is toch paintball??

[mithras]

shorttracker schreef op vrijdag 23 maart 2007 @ 15:39:
airsoft is toch paintball??

Airsoft is met luchtdruk softkogels afschieten (what's in the name ). http://www.youtube.com/wa...puGQ&mode=related&search=

[Verwijderd]

Belgie aanwezig enneuh wth, tis niet alsof er hier enkel en alleen airsoft gespeeld wordt hoor

[mithras]

Verwijderd schreef op vrijdag 23 maart 2007 @ 15:50:
Belgie aanwezig enneuh wth, tis niet alsof er hier enkel en alleen airsoft gespeeld wordt hoor

Maar het is in Nederland verboden, en in Belgie niet

Maar @Sprite_tm: lukt het met de VM? Het is leuk als wel allemaal ideeen erom heen gaan verzinnen, het hangt nu even van jou af Niet dat het snel af moet, maar hebben er meer mensen ervaring met een VM schrijven, en zijn alle brainstormsessies nu genoeg geweest voor het compleet kunnen uitwerken van een VM? Het is dan namelijk mogelijk om eens wat te gaan maken in plaats van alleen die discussie

[shorttracker]

nou, als ik me niet vergis:
Kunnen we neit alvast de software/hardware voor het geweer gaan ontwerpen?
Dit heeft niets te maken met de VM, en kan dus nu ontwikkeld worden.

Is het alleen de vraag WAT er in het geweer allemaal moet gebeuren, ik heb al een redelijke lijst gemaakt in de wiki, maar die moet nog uitgebreider, en iedereen moet het er mee eens zijn (meerderheid dan )

[GeertJohan]

Verwijderd schreef op vrijdag 23 maart 2007 @ 15:50:
Belgie aanwezig enneuh wth, tis niet alsof er hier enkel en alleen airsoft gespeeld wordt hoor

pff, gelukkig maar, anders had het hele project geen zin voor belgie.

[GeertJohan]

mithras schreef op vrijdag 23 maart 2007 @ 15:54:
[...]

Maar @Sprite_tm: lukt het met de VM? Het is leuk als wel allemaal ideeen erom heen gaan verzinnen, het hangt nu even van jou af Niet dat het snel af moet, maar hebben er meer mensen ervaring met een VM schrijven, en zijn alle brainstormsessies nu genoeg geweest voor het compleet kunnen uitwerken van een VM? Het is dan namelijk mogelijk om eens wat te gaan maken in plaats van alleen die discussie

Ik heb Sprite_tm gisteren gemaild. we moeten eerst even overleg hebben over WAT de VM voor zn kiezen neemt, aannemelijk is dat dit alleen de gameplay is, de VM zelf gaat dus geen protocollen enzo verhandelen. dat is wat Gluggie wilt, en ik eigenlijk ook. maar zoals ik al eerder zij, ik moet ff wachten op mailtje van Sprite_tm.

shorttracker
nou, als ik me niet vergis:
Kunnen we neit alvast de software/hardware voor het geweer gaan ontwerpen?
Dit heeft niets te maken met de VM, en kan dus nu ontwikkeld worden.

Is het alleen de vraag WAT er in het geweer allemaal moet gebeuren, ik heb al een redelijke lijst gemaakt in de wiki, maar die moet nog uitgebreider, en iedereen moet het er mee eens zijn (meerderheid dan )

ksal ff kijken,

[Sprite_tm]

Ik ben maar eens begonnen aan het designen van de instructieset van onze virtuele machine. Tis echter een klotejob, dus ik zou het helemaal niet erg vinden als mensen met wat assembly-kennis (bij voorkeur met ervaring met meerdere processoren) me even een handje zouden helpen. Wiki-pagina is hier te vinden.

[slopert]

En ik zie dat de discussie in het Engels gestart is. Op de toekomst voorbereid. Ziet er spanned uit en ik begrijp er ook nog wat van.
Ik neem even aan dat ISA staat voor Instruction System Architecture?

[ Voor 21% gewijzigd door slopert op 24-03-2007 14:56 ]

[Sprite_tm]

Eerste regel:

Before creating a VM, we'll have to design the instruction set architecture (ISA) of the processor we're 'emulating'. Note: ISA has nothing to do with the same-named PC-bus.

[slopert]

Lezen is ook een vak
Voor welke processor wordt de eerste versie van de vm gemaakt? Mega of pic?

[ Voor 57% gewijzigd door slopert op 24-03-2007 17:04 ]

[Phalox]

Gebuisd zeker?
Ik hoop dat er ooit nog een moment komt waarop ik kan meedoen, want nu is dat niet het geval!

[Kek]

tokesnugerd schreef op zaterdag 24 maart 2007 @ 16:41:
Gebuisd zeker?
Ik hoop dat er ooit nog een moment komt waarop ik kan meedoen, want nu is dat niet het geval!

alles op zn tijd, zodra de electronika en de software enigzins vaststaat, wil ik ook wel een setje aanschaffen om er iets leuks van te maken

[GeertJohan]

Binnenkort zal ik een op de wiki een pagina maken waarop de (speciale) functies staan die in de VM komen te zitten.
denk aan:
PrintLCD(int,string);
int: line(1 or 2)
string: message(max. 16 char's)

natuurlijk is dat allemaal "to be edited", een voorstel dus.

mocht nog je een voorstel hebben, post hem dan gerust hieronder.

[ Voor 11% gewijzigd door GeertJohan op 24-03-2007 21:32 ]

[shorttracker]

een beetje de standaard output:

Play.Sound(geen idee wat)
SendIR(int)
int = de code die verzonden moet worden.

Send.clip(int)
int = Hoeveel rounds er worden toegevoegd, en de informatie van de kogel zelf (TeamID,PlayerID,Dammage)

[Verwijderd]

GJR - Squarc schreef op zaterdag 24 maart 2007 @ 21:21:
Binnenkort zal ik een op de wiki een pagina maken waarop de (speciale) functies staan die in de VM komen te zitten.
denk aan:
PrintLCD(int,string);
int: line(1 or 2)
string: message(max. 16 char's)

natuurlijk is dat allemaal "to be edited", een voorstel dus.

mocht nog je een voorstel hebben, post hem dan gerust hieronder.

Misschien de functie uitbreiden
PrintLCD(int,string, time);
int: line(1 or 2)
string: message(max. 16 char's)
time: time(tijd in seconden hoelang het bericht op het display moet blijven, waarna deze weer automatisch op blanco gaat, eventueel is dit een optionele variabel, die ook weggelaten kan worden)

En line zou misschien overbodig zijn, aangezien het zo gemaakt kan worden dat de laatste 2 berichten op het scherm komen? (dus scrollend als het ware)

Of misschien 1 regel van het scherm standaard gebruiken voor ammo, health en de andere regel voor text-messages?

Het zijn maar ideeën wat allemaal met het schermpje gedaan kan worden

Ik kan geen assembly, of de vm zelf programmeren, maar heb wel genoeg programmeer-ervaring om mee te werken aan het schrijven van de VM-programma's

[ Voor 22% gewijzigd door Verwijderd op 24-03-2007 22:08 ]

[mithras]

Verwijderd schreef op zaterdag 24 maart 2007 @ 22:01:
[...]

En line zou misschien overbodig zijn, aangezien het zo gemaakt kan worden dat de laatste 2 berichten op het scherm komen? (dus scrollend als het ware)

Of misschien 1 regel van het scherm standaard gebruiken voor ammo, health en de andere regel voor text-messages?

Het zijn maar ideeën wat allemaal met het schermpje gedaan kan worden

Hoewel dit soort dingen meer voor de wiki is, en nog redelijk onnodig ook omdat het meer aan de programmeur ligt waarvan ik verwacht dat die dit soort dingen wel kan. Maar handiger is om een template te maken lijkt me.
Je hebt een aantal variabelen (ammo, health, armor, reload, bullets, rounds en text) die je met een template "zelf" kan plaatsen. Als jij graag een 4x128 lcd wilt, dan kan je in de template aangeven wat waar komt te staan, en hoef je alleen maar lcd teksten te sturen voor de specifieke onderdelen (ammo, health enz).

[GeertJohan]

Verwijderd schreef op zaterdag 24 maart 2007 @ 22:01:
[...]

Misschien de functie uitbreiden
PrintLCD(int,string, time);
int: line(1 or 2)
string: message(max. 16 char's)
time: time(tijd in seconden hoelang het bericht op het display moet blijven, waarna deze weer automatisch op blanco gaat, eventueel is dit een optionele variabel, die ook weggelaten kan worden)

En line zou misschien overbodig zijn, aangezien het zo gemaakt kan worden dat de laatste 2 berichten op het scherm komen? (dus scrollend als het ware)

Of misschien 1 regel van het scherm standaard gebruiken voor ammo, health en de andere regel voor text-messages?

Het zijn maar ideeën wat allemaal met het schermpje gedaan kan worden

Ik kan geen assembly, of de vm zelf programmeren, maar heb wel genoeg programmeer-ervaring om mee te werken aan het schrijven van de VM-programma's

het word meer als dit:

code:

function resetLCD() {
 //print health bar on line 1
 //print ammo and firerate on line 2
 }

function printGameStart(){
 PrintLCD(1,"");
 PrintLCD(2,"");
 Pauze(100);
 PrintLCD(1,"welcome");
 Pauze(200); 
 PrintLCD(2,"Game Started");
 pauze(600);
 resetLCD();
 }

door in je scripts te bepalen waneer er iets word geprint en voor hoeland kun je veel dynamischer te werk gaan en zit je niet vast aan de limieten van een functie.
je zou nu bijv. een script kunnen schrijven waarbij een message blijft staan tot je schiet/word geraakt of firerate veranderd. zodra je dat doet krijg je pas een resetLCD();
iets wat ik zelf het mooist zou vinden omdat je dan in alle rust je message kan lezen.
tenzij je natuurlijk geraakt word 1 sec na je message. daar moet dus weer een beveileging tussen zitten. maar dat is allemaal van later zorg.

[ Voor 4% gewijzigd door GeertJohan op 24-03-2007 23:37 ]

[Verwijderd]

GJR - Squarc schreef op zaterdag 24 maart 2007 @ 23:33:
[...]


het word meer als dit:

code:

function resetLCD() {
 //print health bar on line 1
 //print ammo and firerate on line 2
 }

function printGameStart(){
 PrintLCD(1,"");
 PrintLCD(2,"");
 Pauze(100);
 PrintLCD(1,"welcome");
 Pauze(200); 
 PrintLCD(2,"Game Started");
 pauze(600);
 resetLCD();
 }

door in je scripts te bepalen waneer er iets word geprint en voor hoeland kun je veel dynamischer te werk gaan en zit je niet vast aan de limieten van een functie.
je zou nu bijv. een script kunnen schrijven waarbij een message blijft staan tot je schiet/word geraakt of firerate veranderd. zodra je dat doet krijg je pas een resetLCD();
iets wat ik zelf het mooist zou vinden omdat je dan in alle rust je message kan lezen.
tenzij je natuurlijk geraakt word 1 sec na je message. daar moet dus weer een beveileging tussen zitten. maar dat is allemaal van later zorg.

Ahh, dit is inderdaad wel flexibel. Maar ik dacht juist dat het plan was om extreem veel functies low-level te programmeren, om maar zeer minimalistische VM-programma's te krijgen.
Ik weet natuurlijk niet of het mogelijk is om een programma van bijvoorbeeld 10kb met een 'IR-kogel' te versturen aan het begin van een spel. (wat toch de bedoeling is met bijvoorbeeld meerdere aangepaste speltypes?)

[mithras]

Verwijderd schreef op zondag 25 maart 2007 @ 00:03:
[...]


Ahh, dit is inderdaad wel flexibel. Maar ik dacht juist dat het plan was om extreem veel functies low-level te programmeren, om maar zeer minimalistische VM-programma's te krijgen.
Ik weet natuurlijk niet of het mogelijk is om een programma van bijvoorbeeld 10kb met een 'IR-kogel' te versturen aan het begin van een spel. (wat toch de bedoeling is met bijvoorbeeld meerdere aangepaste speltypes?)

Een max van 115.2kbps = 14.4kBs. En ik neem aan dat je kB ipv kb bedoelt, dus met het opzoeken, connecten en overzetten met niet de maximale snelheid zit je nog steeds wel onder de 2 a 3 seconden lijkt me.

[Sprite_tm]

Mensen, mag ik u allen verzoeken om de beer niet te verkopen voor 'ie geschoten is? FragL is een leuk idee, maar imo pas iets wat geimplementeerd moet worden zodra we de eerste spelletjes (dus op werkende hardware, met werkende communicatie en een werkende VM) daadwerkelijk gespeeld hebben. Pas dan weten we hoe alles aangestuurd moet worden en dus met wat voor soort verschillende hardware we opgezadeld kunnen zitten: als je het verhaal hierboven implementeerd zit je namelijk meteen vast aan iets wat tweeregelig is en karakters kan weergeven, terwijl het imo alles tussen 2 RGB-ledjes (om ammo en health aan te geven) en een complete PDA moet kunnen wezen. De limieten daarvan (die je nodig hebt om je FragL-functies te ontwikkelen) kom je pas te weten als je daadwerkelijk de hardware- en protocolspecs in handen hebt.

Vrees verder niet dat we niet kunnen gamen totdat FragL compleet af is: de eerste spelletjes zullen weliswaar in assembly geschreven moeten worden, da's echter geen garantie voor minder fun

Het is in de eerste instantie veel belangrijker om een stevige foundation voor de VM te hebben (dat doe ik wel, maar ik zou graag zien dat iedereen met wat assembly-kennis meekijkt) maar ook het protocol tussen PU, geweer, LCD en andere units moet nog ontwikkeld worden. Jullie hebben collectief daar genoeg ideeen en kennis over, ik zou zeggen: doe es een gooi

[ Voor 15% gewijzigd door Sprite_tm op 25-03-2007 00:20 ]

[Phalox]

Misschien op z'n visual basics werken ? dat is nogal intiutief.
LCD.Print.text.line1 = "..."

(maar een dom voorbeeld dat zeker niet zo handig is, maar je kan met andere dingen wel makkelijk verder

[GeertJohan]

tokesnugerd schreef op zondag 25 maart 2007 @ 11:25:
Misschien op z'n visual basics werken ? dat is nogal intiutief.
LCD.Print.text.line1 = "..."

(maar een dom voorbeeld dat zeker niet zo handig is, maar je kan met andere dingen wel makkelijk verder

we laten nu de FragL ff liggen.
je kunt wel ff intikken op de wiki.

[Sprite_tm]

Nou, de mnemonics voor de VM liggen atm redelijk vast. Ik mis alleen nog input/output-routines en de details van de interrupts, maar daarvoor moet ik weten hoe de bus (dus de verbinding tussen het LCD, geweer, PU, sensoren, ...) inelkaar gaat zitten. Als dat uitontwikkeld is wil ik aan het coden van de VM beginnen. (Ik heb trouwens ws as ma t/m wo minder access tot Internet, kan zijn dat ik dan brak reageer. Ik kan iig vrijdag weer hiermee bezig.)

[Scout77]

Ik wilde een beetje gaan prutsen met de hardware en dan de electronica kant van het geheel. Welk programma is het mooiste om electronica schema's in te maken? Of gaan we afspreken het allemaal in hetzelfde prog te gaan doen, wel het makkelijkste denk ik. Ik heb nu Eagle maarja dan heb je voor de free version direct een beperkte printplaat grote, lijkt me niet handig.

[Falcon]

Om dit van de grond af te krijgen als 1 team en niet als allemaal individuele probeersels, zouden jullie denk ik eerst maar eens moeten gaan kijken naar een structeer in dit project. Per onderdeel een "teamleider" die de kar trekt.

Wat ook heel goed werkt is een IRC sessie 's avonds houden.. alle ideeen op 1 tafel en dit notuleren. Daarna nog een keer sessie doen en dan keuzes maken.

Met openfrag.org zijn wij ook zo toen begonnen @ GoT. Succes!

Bron: \[3d Game Project] OpenFRAG *

[Scout77]

Dat IRC lijkt me wel een goed idee. Heb net geprobeerd er een op te zetten op mijn server ... maar op een of andere manier lukt me dat niet. Als iemand een IRC kanaal kan aanmaken zou dat mooi zijn.

[mithras]

Wat denk je van #openlaserfrag @ irc.tweakers.net

[Scout77]

mithras schreef op maandag 26 maart 2007 @ 11:42:
Wat denk je van #openlaserfrag @ irc.tweakers.net

Dusss ..... dacht ik het even fijn moeilijk op te lossen
Ik zit er op iig

[!kke]

ikke ben er ook

[GeertJohan]

offtopic:
!kke schreef op maandag 26 maart 2007 @ 13:47:
ikke ben er ook

fijn!!

En dan nu weer ontopic:
Ik ben bezig alle bestaande code door te lezen.
Binnenkort worden er waarschijnlijk teams gemaakt (zie wiki) voor:
-software
-hardware
-behuizing(nog niemand aangemeld )

maar ehm, wat zijn jullie nu aan het doen?
Het zou opzich wel handig zijn als alle sofware mensen de code snel doorlezen(dus dat je begrijpt welk bestand wat doet).
Ben je van de hardware kant?? mischien kan je wat onderzoek doen naar de te gebruiken electronica en voordelen en nadelen posten op de betreffende wiki pagina.

alles vrijwillig natuurlijk

zet wel ff je naam onder je werk

[ Voor 3% gewijzigd door GeertJohan op 26-03-2007 14:51 ]

[slopert]

Kan wel redelijk solderen, hardware ontwerp kan ik misschien wel in meekomen. Programmeren helemaal niet.
Hier kan je je opgeven http://openlaserfrag.org/wiki/index.php/Teams al had ik wel iets anders verwacht van teams.

[GeertJohan]

slopert schreef op maandag 26 maart 2007 @ 21:28:
Kan wel redelijk solderen, hardware ontwerp kan ik misschien wel in meekomen. Programmeren helemaal niet.
Hier kan je je opgeven http://openlaserfrag.org/wiki/index.php/Teams al had ik wel iets anders verwacht van teams.

Dit is de simpele software hardware scheiding. met deze info worden teams samengesteld en vervolgens kunnen jullie nog wijzegen of switchen tussen teams, al word dat niet verwacht.
zo komt er een team dat vooral electronica bepaald en een team dat soldeerd en printjes maakt.
een team dat assembly doet, vooral de low-level programering, en het team dat de FragL gaat ontwerpen en de high-level programering doet.
dus waarsch 2 hardware teams en 2 software teams. met ieder een coordinator. met daarboven weer een coordinator. behoorlijk officieel allemaal en misch ook wel een beetje irri. maar wel een makelijkere werksfeer. je weer precies wie je waarop moet hebben en Teams krijgen eigen poll pagina.

[Verwijderd]

Scout77 schreef op maandag 26 maart 2007 @ 01:02:
Ik wilde een beetje gaan prutsen met de hardware en dan de electronica kant van het geheel. Welk programma is het mooiste om electronica schema's in te maken? Of gaan we afspreken het allemaal in hetzelfde prog te gaan doen, wel het makkelijkste denk ik. Ik heb nu Eagle maarja dan heb je voor de free version direct een beperkte printplaat grote, lijkt me niet handig.

Ik gebruik momenteel Altium designer 6.x, maar dit kost algauw 10.000 euries voor 1 licentie.
en nee geen demos te verkrijgen.
Jammer want dit progsel is one of a kind.
En langs mijn kant ga je me niet kunnen overhalen om dingen te tekenen is freagel oid.

[mithras]

Geen idee of de software wat is om mee te werken (en of dit nu de juiste software is wat je zoekt), maar is het niet een idee om ook dat uit een lijstje van open source software te kiezen

Hier bijvoorbeeld, of hier

[slopert]

GJR goed idee ik heb me al opgegeven.
Voor pcb design zou eagle moeten volstaan, de borden zouden niet al te ingewikkeld moet worden.De grootte van het bord is voldoende en er is geen limiet op de pin count. Eventueel zouden er twee borden via een header aan elkaar te maken zijn.