 Amby | Skrevet 15/05-13 22:51 | | Hvad med os som stadig hænger i PHP? :) | Have no thing I'd rather see, Since I found Serenity.Spiller nu: Mirror's Edge, Resistance 2
|
|
|
|
|
|
 dRxL | Skrevet 16/05-13 10:47 | Jeg skipper nok at kigge forbi dig i dag så, og gemmer det til jeg har bedre tid. Du kan evt. give lyd når 8-player bordet er oppe at køre.
Eller jeg kan måske hjælpe hvis får problemer med at få det til at køre på den tiltænkte hardware.
Må indrømme at jeg er begyndt at fabulere lidt over andre spilkoncepter for 8 spillere med 2 knapper hver. Ville du være åben for at køre andet end Light Cycle på bordet hvis jeg kan finde på og implementere noget godt? | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
|
|
 slk486 | Skrevet 16/05-13 11:13 | | Ha! Jeg har ikke kodet noget i assembler siden DOS og Amiga dagene :) Følelsen af nærhed med hardwaren og at presse citronen til sidste dråbe and beyond. Ahh... | j/k
|
|
 KillerBean2 | Skrevet 16/05-13 11:58 | Præcis. Jeg er ufattelig dårlig til programmering. Jeg har et ret dårligt "sprogøre", men er tosset glad for hardware, så assembler ligger lige til højrebenet. Det er ret befriende, at der ikke nogen, som fortæller "hvordan man gør". Man finder bare en liste over de instruktioner, man har til rådighed, og bruger så ikke andet end sin fantasi og logiske sans for at få tingene til at virke.
At det så tager en helvedes tid at få det til at fungere, er en anden sag :D | AV Intelligent Terminal
|
|
 varmtvand | Skrevet 16/05-13 13:28 | dRxL>
Jeg skipper nok at kigge forbi dig i dag så, og gemmer det til jeg har bedre tid. Du kan evt. give lyd når 8-player bordet er oppe at køre.
Eller jeg kan måske hjælpe hvis får problemer med at få det til at køre på den tiltænkte hardware.
Må indrømme at jeg er begyndt at fabulere lidt over andre spilkoncepter for 8 spillere med 2 knapper hver. Ville du være åben for at køre andet end Light Cycle på bordet hvis jeg kan finde på og implementere noget godt?
Ok tak. Skriver hvis vi har brug for noget hjælp. :)
Ang. Spilkoncepter/spil vil det være mega fedt med flere. Man kunne også 4 player spil med 4 knapper hver. Eller et 1 player spil med 16 knapper. El. 16 player spil med...:)
Så ku man lave et event ud af det.
Måske også få flere til at bygge en tilsvarende maskine. | Retro spil butik Spiller nu: Batsugun, Solar Striker, Legend Of Zelda, The: O...
|
|
 quad | Skrevet 16/05-13 18:11 | | Jeg vil gerne foreslå et kaotisk 8-player PONG, med minimum to-tre samtidige bolde. |
|
 Sumez | Skrevet 22/05-13 08:34 | KillerBean2>
Præcis. Jeg er ufattelig dårlig til programmering. Jeg har et ret dårligt "sprogøre", men er tosset glad for hardware, så assembler ligger lige til højrebenet. Det er ret befriende, at der ikke nogen, som fortæller "hvordan man gør". Man finder bare en liste over de instruktioner, man har til rådighed, og bruger så ikke andet end sin fantasi og logiske sans for at få tingene til at virke.
Det er essensen af al programmering, forskellen er blot hvilket niveau du arbejder på. :) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| KillerBean2 | Skrevet 22/05-13 10:53, rettet 22/05-13 10:54 | Jeg kan godt se, hvad du mener, men jeg tror alligevel, du misforstår det, jeg skriver :)
Egentlig prøver jeg bare at skrive, at jeg er glad for, at man stort set ikke har nogen syntax i assembler. Man kan næsten ikke skrive noget kode, som er "forkert". Hardwaren gør alt, hvad man beder den om, uanset om det er en tumpet eller genial handling. Det er svært at lave "grammatiske" fejl. Det er det, jeg finder befriende. | AV Intelligent Terminal
|
|
| Sumez | Skrevet 22/05-13 11:07 | | Nej jeg forstår helt fint hvad du mener, og kan også godt se charmen i det. :) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| KillerBean2 | Skrevet 22/05-13 11:13 | | Jeg kan også godt se charmen i objektorienteret programmering :D | AV Intelligent Terminal
|
|
| dRxL | Skrevet 22/05-13 12:12 | Sumez>
Religionskrig og smagssag, og der er store gode træk i begge ender, og jeg synes "det sjoveste" findes i ekstremerne, som C# og Ruby on Rails f.eks. repræsenterer. Hvis du arbejder på kæmpeprojekter, er det nærmest livsnødvendigt med typestærkhed og "tvungen" OOP, og jeg synes selv C# er et fantastisk sprog/framework at arbejde i!
Hvis dit sprog er ikke-typestærkt, giver det selvfølgelig en masse andre friheder, der er helt fantastiske, som ganske rigtigt gør sprog som Python og JavaScript rigtig fornøjelige. Men jeg ville ikke -selv- lave et spil i dem.
Jeg orker simpelthen ikke at gå i gang med at pille ovenstående fra hinanden, især ikke da du givet bare bliver defensiv og alligevel ikke forstår halvdelen af hvad jeg i så fald har brugt pænt megen tid på at skrive og underbygge med referencer. Men jeg vil ikke lade det stå uimodsagt, så lad mig blot konstatere at jeg ser flere dybt forkerte påstande i det du skriver end der er sætninger og at jeg faktisk bliver lidt hidsig når jeg ser det. Men hvis du kan tjene gode penge ved at programmere med den grad af viden om programmering du giver udtryk for, er det vel en god ting... for dig. | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
| Sumez | Skrevet 22/05-13 12:18 | | Bare bliv ved i den tro. Hvis du seriøst mener at typestærkhed og OOP ikke tjener noget formål, og blot er mere besvær and det er værd, er det dit eget problem, og ikke noget du behøver at tørre af på mig, i et ringe forsøg på at få mig til at fremstå som om jeg ikke ved hvad jeg snakker om. | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
|
|
| slk486 | Skrevet 22/05-13 15:57 | | *must...also...resist...* | j/k
|
|
| KillerBean2 | Skrevet 22/05-13 16:19 | | *Finder en spand popcorn frem* | AV Intelligent Terminal
|
|
|
|
| dRxL | Skrevet 28/05-13 15:59, rettet 28/05-13 22:41 | 5 spillere (én Wiimote, 3 xbox 360 kontrollere og én dualshock3) i filmen:
http://www.youtube.com/watch?v=297vo7mYgw8
Har haft 6 kontrollere på samtidig og er lidt i tvivl om hvor den øvre grænse for SDL går, men finder nok ud af det en dag ;)
Gameplay er det samme som dreamcast versionen, men mangler de fine lyspor/haler og forskelligt menuværk, evt. lidt gameplay variation. | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
|
|
 Herold | Skrevet 30/05-13 20:22 | | Det ser sgu godt ud. Du må lige sige til når det er færdigt - så skal det da ud omkring og spilles! | This isn't life in the fast lane. This is life in oncoming traffic.Spiller nu: Left 4 Dead 2
|
|
| dRxL | Skrevet 02/07-13 12:23, rettet 02/07-13 13:01 | Er begyndt porte renderingen til GLSL shadere. Brugte denne teknik til at highlighte wireframes i modellerne:
http://www2.imm.dtu.dk/~janba/Wireframe/
De fyre fra DTU der har lavet teknikken, har været rimeligt snu. Det er single-pass og naturligt anti-aliased, kun ved brug af den linæere interpolation der alligevel er indbygget i moderne grafikkort.
Planen er lidt at rendere spillet til en buffer som så bliver lagt som en tekstur ovenpå et grid der folder ude i siderne som et gammelt CRT fjernsyn. På en måde så det bliver mere intuitivt at banen folder rundt om sig selv.
Med visualisering af grid'et håber jeg hurtigt at kunne kommunikere andre interessante foldninger af et 2D plan. f.eks. donuts (hul i midten af skærmen der folder til kanterne) eller andet spas.
Mere om det når jeg finder tid til at implementere det hele =)
edit: download af roterend wireframe tepotte for mac ejere http://ndrx.net/tmp/q_wireframe.app.zip | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
|
|
|
|
 RJK | Skrevet 05/08-13 17:53 | Jeg troede at meningen med det "foldede" område var at det overlappede - altså når ting x forsvinder ud i bunden, så burde det være på folden både i bunden og i toppen på samme tid.
At gøre det med eksplosionerne ville nok forvirre mere end det gavner, men for både spillere og skud ville det gøre det nemmere at aflæse. | »This Is Beginning Of A Fantastic Story«Spiller nu: Fire Emblem: Three Hous..., Hellblade: Senua's Sacr..., Fire Emblem Fates
|
|
| dRxL | Skrevet 05/08-13 18:15 | Det er også meningen på lidt længere sigt og jeg burde også kunne gøre det relativt let med den renderer jeg har nu, hvor jeg først tegner spillet nogenlunde som jeg altid har gjort men til en tekstur som så lægges ovenpå det bøjede grid. I så fald skal jeg blot gøre den tekstur jeg renderer til tilsvarende meget større for overlap området og så tegne (sample) det der bliver skåret fra på den modsatte side.
Det er også muligt at det ganske enkelt er lettest at rendere ting tæt på kanterne 2 gange.
Problemet er bare at kollisioner pt kun beregnes ifhld til én position ad gangen, så hvis jeg tegner spillet anderledes bør jeg næsten også lave kollisionsberegningerne så de også tager højde for muligheden for at et objekt kan være på flere forskellige koordinater samtidig.
Den ændring kommer jeg nok også til at lave med tiden, men mit første mål, som jeg endnu ikke helt har nået, er at lave spillet så tro i forhold til den oprindelige Dreamcast udgave, at de joystick input optagelser Dreamcast udgaven af spillet viser i sin "attract-mode" vil fungere i den nye version også.
Jeg har i øvrigt også tænkt at eksplosionerne nok ikke skal "wrappes" rundt om spilleområdet. Primært af den tekniske årsag at de er så store at de ville tvinge størrelsen på min back-buffer texture meget op. Jeg tænker i stedet lidt på at de evt. kunne renderes i det model-space som det bøjede grid og derved også ende med at "flyde" udover dette". | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
| RJK | Skrevet 05/08-13 18:23, rettet 05/08-13 18:38 | On top of my head skal du vel hverken ændre størrelsen eller kollisionerne. Alle spillere, skud og miner som findes indenfor (X) af kanten (=størrelsen af folden) skal bare tegnes i en dummy-kopi på position (bredde-X), tilsvarende for Y, og tilsvarende for X+Y (hjørnerne). Så burde det hele fungere korrekt stadigvæk.
EDIT: Eneste visuelle issue vil være hvis en ting eksploderer mens den er i folden. Så vil eksplosionen kun komme fra den "rigtige" position. Men om man vil se det meget i praksis - ikke sikkert...
EDIT2: Okay, jeg kan godt se det med størrelsen nu :) | »This Is Beginning Of A Fantastic Story«Spiller nu: Fire Emblem: Three Hous..., Hellblade: Senua's Sacr..., Fire Emblem Fates
|
|
|
|
|
|
| dRxL | Skrevet 07/08-13 01:36, rettet 07/08-13 01:37 | Så fik jeg genoplivet nogle af de gamle replays, dog ikke 100% korrekt afspilning, og spørgsmålet er også om det overhovedet er umagen værd taget i betragtning at der skal kæmpes med forskelle i endianness, forskelle på størrelsen på pointere og andet gejl.
Men jeg synes selv det er ved at være ret pænt, mangler måske lige de lyspor efter spibene der var i dreamcast udgaven.
http://www.youtube.com/watch?v=X8SMTEe_agU&hd=1 | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
|
|
| Sumez | Skrevet 12/08-13 22:08, rettet 12/08-13 22:09 | Jeg er lige gået i gang med en simpel 2D engine i Mono. MonoGame er et fremragende framework, baseret på Microsoft's XNA Framework, der IMO er noget af det bedste de har lavet - bare som open source, med mulighed for porting til alverdens platforme. Bl.a. Fez er lavet i MonoGame, Rogue Legacy og Bastion er lavet i XNA (og sidstnævnte portet vha. MonoGame).
Jeg har rodet med den slags mange gange før, men for at komme ordentligt igang, vælger jeg denne gang at lave en fungerende engine med level editor osv. før jeg begynder at indsætte spillogik.
Mit mål er at lave en bane der spiller i stil med Mega Man X, så har jeg et godt udgangspunkt at bygge videre på, og grafik-assets der er nemme at stjæle, indtil jeg får fat i en grafiker. :)
Pt. er det muligt at designe animationer ud fra spritesheets, og knytte et antal sprites og hitboxes til hvert objekt i en scene.
Der er lang vej endnu :) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
|
|
| Sumez | Skrevet 13/08-13 09:03 | Ja planen er open source, men ikke før jeg har noget der spiller, og været igennem en masse performance-optimering. :) Lige nu tjekker collisions på alle sider uden nogen form for pruning eller quad-trees.
Min udfordring lige nu hedder at når jeg -har- en kollision mellem to simple polygoner, har jeg brug for flere detaljer om kollisionen, navnligt normalen på den overflade man har ramt (hvilket i teorien kan være et problem hvis hver polygon rammer med flere sider på én gang)
Det ville være simpelt nok med rektangler eller trekanter, og jeg har i forvejen indekseret alle kollisionsbokse som en serie trekanter (som grafikkort arbejder med), men er ikke sikker på at det er "safe" bare at behandle hver trekant som sin egen hitbox. Reelt set skal jeg vel bare have de to ydre overflader der overlapper mindst (i forhold til deres normal) - det lyder simpelt nok, men jeg er ret sikker på at jeg løber ind i diverse problemer. :) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| slk486 | Skrevet 13/08-13 09:18 | Jeg elsker bare performanceoptimering. Blevet lidt kedeligere med nymodens maskiner, men i gamle dage... :)
Der findes 2D engines i forvejen - er det for øvelsens skyld du vil lave din egen? | j/k
|
|
| Sumez | Skrevet 13/08-13 09:44, rettet 13/08-13 09:49 | Jeg elsker bare performanceoptimering. Blevet lidt kedeligere med nymodens maskiner, men i gamle dage... :)
Jeg foretrækker selv at arbejde med forretningslogik og modeller - geometriske algoritmer er nok der hvor jeg går allermest i stå, når det kommer til det her (hvilket også er en af årsagerne til at jeg tvinger mig selv til at arbejde med det).
Men det er sjovt at lave performance-tweaks i sit program, når man kan se effekten. ;) Men jeg bør nok huske at følge den gyldne regel om aldrig at optimere på steder hvor man ikke kan måle en reel flaskehals.
Der findes 2D engines i forvejen - er det for øvelsens skyld du vil lave din egen?
Der er mange årsager. :)
Kontrol, fleksibilitet, simplicitet, og ja, i den grad erfaring.
Hvis jeg f.eks. skulle til noget gamejam af en art, ville det være en fordel at have en engine, man er erfaren med, og ved hvordan fungerer. Jeg synes alt for tit jeg har oplevet at gå i gang med engines som jeg efter flere uger ikke kan få til at gøre bestemte ting, eller kræver dumme omveje for at få til at gøre det man har brug for, eller som jeg konstant skal sidde med en reference ved hånden for at bruge.
Omvendt kan de også være "for" åbne, og så er man som udvikler alligevel nødt til at stykke sin egen mere målrettede engine sammen i det framework man har til rådighed. Reelt set er MonoGame jo allerede en 2D (og 3D) engine i forvejen. Der er rigtig meget af det tekniske, der er ordnet for en, så man kan koncentrere sig om at kode "pænt" i stedet.
Jeg har førhen lavet spadestik til en 2D engine i C++ (kom ikke så langt, men den kunne da rendere objekter med animerede sprites ud fra teksturer og definitioner der loades ind fra en samlet fil), for at prøve at starte "fra grunden", men ved at bruge C# og MonoGame frameworket er det 100 gange hurtigere at komme frem til synlige resultater... Til gengæld savner jeg dog virkelig at kunne sende værdierne fra en liste direkte til en funktion, fremfor en reference. Selv arrays er altid reference type i C#, hvilket kan være lidt hårdt på RAM'en i særligt krævende algoritmer.
Men hvis jeg havde regnet med at memory management bliver et problem, var jeg ikke gået i gang med Mono/C#. :)
Primært er årsagen dog lige nu "for at lave den". Fordi mit mål ikke er at lave et spil (det langsigtede mål er, men har ikke noget målrettet projekt pt.), så lige nu er mit mål at lave en fungerende engine. :) Jeg er ikke i tvivl om at det er muligt at finde en engine (open source, om ikke andet), der kan det jeg har brug for, men så ville jeg jo ikke kunne få lov til at lave den selv. :P
Tænker du selv på nogle 2D engines, som du mener er gode at arbejde med? | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| slk486 | Skrevet 13/08-13 10:39, rettet 13/08-13 10:40 | Du kan arbejde med fixed buffers i C#, hvis du vil have arrays som valuetype, men jeg kan ikke se hvad du vil have ud af det - hverken RAM- eller performancemæssigt.
Nej jeg tænkte ikke på nogen specifik - blot at rigtig mange gør den fejltagelse at opfinde den dybe tallerken, istedet for at bruge eksisterende værktøjer og komme videre :D | j/k
|
|
| Sumez | Skrevet 13/08-13 10:48, rettet 13/08-13 10:48 | Du kan arbejde med fixed buffers i C#, hvis du vil have arrays som valuetype, men jeg kan ikke se hvad du vil have ud af det - hverken RAM- eller performancemæssigt.
Ved mange loops med funktionskald, kan du bevare din data på stack'en i stedet for hele tiden at flytte din memory pointer frem og tilbage mellem heap og stack. Det er en flaskehals der opstår af at RAM bliver langsommere og langsommere i forhold til udviklingen af CPU'er. Det er ikke det store problem på moderne pc'er (eller, kommer jo nok an på dit produkt), men da jeg engang prøvede at porte et program til X360 løb jeg ind i problemet, så jeg er altid opmærksom på det nu.
Nej jeg tænkte ikke på nogen specifik - blot at rigtig mange gør den fejltagelse at opfinde den dybe tallerken, istedet for at bruge eksisterende værktøjer og komme videre :D
Det kan siges om spiludvikling generelt. ;)
(edit: Eller udvikling i det hele taget... nogen sinde prøvet at arbejde med C5-systemer? >__<) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| dRxL | Skrevet 13/08-13 10:54 | Sumuz>
Til gengæld savner jeg dog virkelig at kunne sende værdierne fra en liste direkte til en funktion, fremfor en reference. Selv arrays er altid reference type i C#, hvilket kan være lidt hårdt på RAM'en i særligt krævende algoritmer.
Kan du uddybe ovenstående, fordi det giver omvendt mening når jeg læser det. Altså at performance forbedres ved brug af reference types, fordi du undgår en masse skrivning til RAM.
Sumuz>
Men det er sjovt at lave performance-tweaks i sit program, når man kan se effekten. ;) Men jeg bør nok huske at følge den gyldne regel om aldrig at optimere på steder hvor man ikke kan måle en reel flaskehals.
Mit bedste råd er at se bort fra performance og i stedet fokusere på funktionaliteten indtil den har den endelige form. | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
| dRxL | Skrevet 13/08-13 11:05 | Sumez>
Ved mange loops med funktionskald, kan du bevare din data på stack'en i stedet for hele tiden at flytte din memory pointer frem og tilbage mellem heap og stack.
Hvem har dog bildt dig det ind?
Der er ganske vidst en forskel mellem heap og stack allokering, men det har noget med din "heap allocator" (typisk malloc) at gøre*, _ikke_ hvor en given pointer peger til.
*implicit også noget med cache-hit rate og memory sequentiality/fragmentation, men det lader vi ligge for nu, da pres på selve heap manageren er flere faktorer vigtigere. | SIMDSpiller nu: Pokémon Ultra Moon, Pokémon Omega Ruby, Pokémon HeartGold
|
|
| slk486 | Skrevet 13/08-13 11:06, rettet 13/08-13 11:11 | Ved mange loops med funktionskald, kan du bevare din data på stack'en i stedet for hele tiden at flytte din memory pointer frem og tilbage mellem heap og stack. Det er en flaskehals der opstår af at RAM bliver langsommere og langsommere i forhold til udviklingen af CPU'er. Det er ikke det store problem på moderne pc'er (eller, kommer jo nok an på dit produkt), men da jeg engang prøvede at porte et program til X360 løb jeg ind i problemet, så jeg er altid opmærksom på det nu.
Ja, der kan være performance at hente i meget stramme loops ved at bruge value types istedet for reference - med "hårdere ved RAM" troede jeg du mente mere forbrug ;)
Som sagt et fixed array i en struct giver dig det du ønsker, men så får du kopieringen istedet.
(edit: Eller udvikling i det hele taget... nogen sinde prøvet at arbejde med C5-systemer? >__<)
Ydrk, nej kun op imod C5-systemer...
@dRxL: Husk vi taler C# her, så ingen malloc;) | j/k
|
|
| Sumez | Skrevet 13/08-13 11:10, rettet 13/08-13 11:11 | duRxL>
Kan du uddybe ovenstående, fordi det giver omvendt mening når jeg læser det. Altså at performance forbedres ved brug af reference types, fordi du undgår en masse skrivning til RAM.
Det kommer selvfølgelig an på hvilken type data du behandler. Hvis der er tale om et relativt lille antal floats kan det være hurtigere at sende værdierne med. Optimalt ville jeg nok kun skrive dem én gang på stacken, og så sende referencer dertil (men tør ikke komme med formodninger), problemet kommer når C# opretter listen direkte på heapen. Det hurtigste ville jo nok være en form for first-in-first-out struktur, men så er vi også ude på et område hvor jeg aldrig nogensinde ville få noget fornuftig ud af at prøve at opfinde den dybe tallerken. ;)
Som du selv skriver nedenfor:
duRxL>
Mit bedste råd er at se bort fra performance og i stedet fokusere på funktionaliteten indtil den har den endelige form.
Enig, det er nok golden rule #1 når det kommer til performance-optimering. :)
slk486>
Ydrk, nej kun op imod C5-systemer...
Det var egentlig også det jeg mente... men så tror jeg også du ved hvad jeg mener :D | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
|
|
| slk486 | Skrevet 13/08-13 11:12, rettet 13/08-13 11:14 | Ja, den bruger formentlig malloc, men min pointe var at du ikke selv kan styrer den:)
duRxL>
Mit bedste råd er at se bort fra performance og i stedet fokusere på funktionaliteten indtil den har den endelige form.
Enig, det er nok golden rule #1 når det kommer til performance-optimering. :)
Word! :D | j/k
|
|
| Sumez | Skrevet 13/08-13 11:14, rettet 13/08-13 11:23 | | Du kan svjv. ikke gør særlig meget for at allokere din hukommelse i C#, den opdeler det via "value types" og "reference types". Hvis en klasse oprettes som struct, behandles den som value type. Alle reference types oprettes på heapen hvor frameworket har lyst til det. | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
|
|
| Sumez | Skrevet 13/08-13 11:47, rettet 13/08-13 11:51 | Hvis du insisterer på at lave alle niveauer af din AAA 3D-engine i C#, ja, så er det nok en dårlig idé (men mest pga garbage collectoren), men så er det jo heldigt at der ikke er noget der afholder dig fra at udbygge med libraries i C, der gør brug assembly-rutiner. Hvis det er det man synes er sjovt, kan man starte der.
Yep, unsafe mode er "redningen" til C#-udviklere, der savner mere kontrol over deres hukommelse. Selvsagt er det ikke noget jeg går i gang med før resten af systemet virker, og jeg har fået sat unit tests op, osv.
Samme gælder multithreading osv. | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
| slk486 | Skrevet 13/08-13 12:01 | | ^ Selvom det er et must at have multithreading for øje fra starten :) | j/k
|
|
| Sumez | Skrevet 13/08-13 12:14, rettet 13/08-13 12:16 | Ikke rigtig i et almindeligt 2D actionspil. ;) Jeg har ikke forventninger om at løbe ind i nogen behov for multithreading, før jeg en dag går amok i mine ambitioner og laver noget helt vildt uventet. :P
edit: Der nok en smule at vinde ved asynkron indlæsning af data, men det er ikke rigtig noget der interefererer med resten af spillet. :) | Spis sundt og tro på dig selvSpiller nu: Gravity Circuit, Bonze Adventure
|
|
copyright Play:Right 2002-2024