---

Jeg har tidligere postet nedenstående i dk.edb.programering, men der
diskuterer man tilsyneladende nu kun hvilket sprog der er bedre end hvilket
andet sprog og hvorfor det er ...*gab*
Da mit emne som sådan ikke behøver behandles som et programeringsproblem,
men mere et datalogisk ditto, poster jeg nu også her i håb om lidt response.

Der er sat fut fra det gamle i dk.edb.programmering til videnskab, men jeg
kan nok desværre ikke splejse de to tråde nu.

Jeg legede for noget tid siden med opbygningen af et landskab i vilkårlig
detaljegrad ved hjælp af algoritmer som blandt andet ROAM.
Se evt. http://www.llnl.gov/graphics/ROAM/roam.pdf
Princippet er simpelt nok. Landskabet er defineret som en række trekanter,
som kan opdeles til mindre og mindre trekanter, til man har vilkårlig
detaljegrad. Man behøver kun at have høj opløsning der hvor man er/kigger og
usete dele af landskabet kan være meget groft opdelt.

Dette muliggører reelt at man kan have et meget stort landskab som
intetsteds er defineret, før nogen ser på det. I det landskabet ses, da
opstår det. Opdelingen afhænger af tilfældige afvigelser, som, hvis de er
pseudotilfældige, vil kunne gendannes præcis fra gang til gang.

Landskaber kan let dannes på denne måde, men andre begreber kan dannes
tilsvarende. Eksempelvis kan man beregne en sansynlighed for forekomsten af
skov i et område som en funktion af landskabet på stedet og et andet
sansynlighedslandskab. Byer, dyreliv og så videre kan genereres dynamisk på
samme måde.

Mit spørgsmål går på hvorfor disse metoder ikke allerede i stor stil er
implementeret i spil? Tanken om et meget detaljeret og praktisk talt
uendeligt stor landskab som man kan gå ind i er da fascinerende. Man kan
dreje om et hjørne og se ud fra den skov man er i, og der ser man et stor
bjerg der i ensom majestæt knejser over en slette med en flod som snoer sig
gennem landskabet. Dette landskab og dette bjerg er ikke set af nogen
mennesker før. Det fandtes end ikke før man så det. Ingen designer har
opfundet bjerget... man opdager det for første gang.
Kommer en anden dagen efter, så ses samme bjerg på samme sted, da der om
sagt er tale om pseudotilfældige tal med seeds, der gør at når samme
landskab beregnes igen, så kommer man til samme resultat.

Er der nogen her som har indsigt i problemstillinger som umuliggører dette i
praksis? Jeg har fra eksperimenter selv at set de skiterede metoder sagtens
kan lave detaljerede landskaber, som kan være ganske store.

Jeg overvejer at lave bachelorprojekt om det i datalogi om ikke så længe,
men ville lige udsende en føler først. Teknologien virker nærmest grænseløs
(indenfor opløsningen af talsystemerne i moderne computere), men alligevel
er den ikke anvendt, som i mit eksempel. Hvorfor ikke? Fordi der er for lidt
kontrol med landskabet, og moderne spil kræver garanti for spændende
landskaber med spændende opgaver rundt om hvert et hjørne? Man skulle da tro
at der ville være et marked for en verden der var tilfældig og hvor man
vitterlig kunne drage på opdagelse. Selv at ændre denne verden kan gøres. Så
skal indformation om ændringen naturligvis lagres, men selv store ændringer
kunne lagres ved få værdier. Eksempel: jeg udløser en kraftig eksplosion et
sted. Den har en effekt på omgivelserne. Denne effekt skal ikke lagres. Når
eksplosionen sker så knyttes et stort tilfældigt tl til den og anvendes som
seed for beregningerne af ændringer i landskabet som følge af eksplosionen.
Jeg kan nu se hullet, og landskabet er ændret. Positionen og det anvendte
"seed" lagres. Næste person der nærmer sig vil forårsage at effekten
genskabes ud fra de få lagrede værdier.

Ja, jeg kunne ævle videre til det atter bliver morgen, men jeg hører meget
gerne eventuelle komentarer.

---

Thomas wrote:

>Jeg har tidligere postet nedenstående i dk.edb.programering, men der
>diskuterer man tilsyneladende nu kun hvilket sprog der er bedre end hvilket
>andet sprog og hvorfor det er ...*gab*
>Da mit emne som sådan ikke behøver behandles som et programeringsproblem,
>men mere et datalogisk ditto, poster jeg nu også her i håb om lidt response.
>
>Der er sat fut fra det gamle i dk.edb.programmering til videnskab, men jeg
>kan nok desværre ikke splejse de to tråde nu.
>
>Jeg legede for noget tid siden med opbygningen af et landskab i vilkårlig
>detaljegrad ved hjælp af algoritmer som blandt andet ROAM.
>Se evt. http://www.llnl.gov/graphics/ROAM/roam.pdf
>Princippet er simpelt nok. Landskabet er defineret som en række trekanter,
>som kan opdeles til mindre og mindre trekanter, til man har vilkårlig
>detaljegrad. Man behøver kun at have høj opløsning der hvor man er/kigger og
>usete dele af landskabet kan være meget groft opdelt.
>
>Dette muliggører reelt at man kan have et meget stort landskab som
>intetsteds er defineret, før nogen ser på det. I det landskabet ses, da
>opstår det. Opdelingen afhænger af tilfældige afvigelser, som, hvis de er
>pseudotilfældige, vil kunne gendannes præcis fra gang til gang.
>
>Landskaber kan let dannes på denne måde, men andre begreber kan dannes
>tilsvarende. Eksempelvis kan man beregne en sansynlighed for forekomsten af
>skov i et område som en funktion af landskabet på stedet og et andet
>sansynlighedslandskab. Byer, dyreliv og så videre kan genereres dynamisk på
>samme måde.
>
>Mit spørgsmål går på hvorfor disse metoder ikke allerede i stor stil er
>implementeret i spil?
>
Fordi spil er lavet til gamle computere, dels er de lave som en
forbedring af Dom eller et andet ældre spil.
Nytænkning kræver mere end penge. Det er alle i virksomheden som skal
tænke på en ny måde.

Men hvis man tænker sig en hel verden så vil der være store tomme have
og øde ørkner.
Og omvendt så kan det blive for meget karstlandskab, hvis man laver
stejle bjerge alle steder.

hvis du er i en skov, så vil du ikke se andet end træer.
På en bjergtop vil du ikke se andet end bjerge.

---

"kvaerulant" <haabet2003@yahoo.dk> wrote in message
news:42354766$0$80880$157c6196@dreader2.cybercity.dk...

>Fordi spil er lavet til gamle computere, dels er de lave som en forbedring
>af Dom eller et andet ældre spil.

Det mener jeg ikke at er korrekt. Det gælder for mange spil, men der er hele
tiden en gruppe som sætter nye krav for maskinerne. Disse spil kan ofte kun
køre optimalt på de kraftigste hjemmecomputere.

>Men hvis man tænker sig en hel verden så vil der være store tomme have og
>øde ørkner.
>Og omvendt så kan det blive for meget karstlandskab, hvis man laver stejle
>bjerge alle steder.
>hvis du er i en skov, så vil du ikke se andet end træer.
>På en bjergtop vil du ikke se andet end bjerge.

Hvad mener du? En stor kunstig verden vil dermed netop ligne den virkelige
verden.
"hvis man laver stejle bjerge alle steder". Nu ved jeg ikke om det er i
overført betydning, eller om du ikke helt er med på metoden, men "man" laver
ikke landskaberne. De laves efter algoritmer som kan generere detaljer
baseret på et element af pseudotilfældighed. Algoritmerne kan så ændres, så
man får forskellige ensartede landskabstyper om man vil.

Det var nu også mere for at høre om der er tekniske problemer med den
skitserede metode, som er til hindre for den. Jeg ved at der kan være
problemer med at repæsentere meget store områder, som eksempelvis
solsystemer eller galakser, med de talstørelser som er understøttet i
hardware (dette problem bliver mindre med 64bit procesorer), men for en
klode bør det kunne virke.
Et link der behandler dette og nogle af problemerne med stiore afstande
http://www.gamasutra.com/features/20010302/oneil_01.htm
Kræver muligvis login på gamasutra, som dog er gratis og reklamefri.

---

On Mon, 14 Mar 2005 08:29:19 +0100, "Thomas" <tg@svar.her.ja> wrote:


>Mit spørgsmål går på hvorfor disse metoder ikke allerede i stor stil er
>implementeret i spil? Tanken om et meget detaljeret og praktisk talt
>uendeligt stor landskab som man kan gå ind i er da fascinerende. Man kan
>dreje om et hjørne og se ud fra den skov man er i, og der ser man et stor
>bjerg der i ensom majestæt knejser over en slette med en flod som snoer sig
>gennem landskabet. Dette landskab og dette bjerg er ikke set af nogen
>mennesker før. Det fandtes end ikke før man så det. Ingen designer har
>opfundet bjerget... man opdager det for første gang.
>Kommer en anden dagen efter, så ses samme bjerg på samme sted, da der om
>sagt er tale om pseudotilfældige tal med seeds, der gør at når samme
>landskab beregnes igen, så kommer man til samme resultat.
>
>Er der nogen her som har indsigt i problemstillinger som umuliggører dette i
>praksis? Jeg har fra eksperimenter selv at set de skiterede metoder sagtens
>kan lave detaljerede landskaber, som kan være ganske store.

Løsningen er såmænd blot at indbygge så mange tilfældighedsparametre i
programmet og via brugerens valgmuligheder (f.ex. de uundgåelige
variationer i musens bevægelser når man udfører den samme handling) at
det er ganske usandsynligt at to brugere nogensinde kommer til at
opleve helt det samme.

Hvor langt man kan nå m.h.t. variation og alsidighed er reelt set blot
et spørgsmål om hvor megen hukommelse man har til rådighed, og hvor
effektivt (rationelt) man via programmeringen udnytter de muligheder
mængden af hukommelse giver. Der vil altid være en naturlig logisk
grænse for hvor megen variation man kan opnå inden for rammerne af et
givet, ikke-uendeligt system, men kan kan jo blot udvide systemet
efter behov.

I princippet er jorden jo i sig selv et sådant system. Går du en tur
på strøget kl. 4 hver dag så vil du aldrig opleve helt præcis den
samme situation, fordi der er så mange variable parametre, i den her
sammenhæng specielt m.h.t. menneskelig aktivitet. Over en længere
periode vil du også opleve at de mere faste parametere som f.ex.
bygninger ændrer sig hen ad vejen. der bliver revet noget ned og
bygget noget andet hele tiden. I et endnu større tidspersepktiv kan
man se hele byer og lande opstå og forsvinde, eller kontinenter flytte
sig rundt på planetens overflade.

Alt dette er udelukkende muligt på grund af systemets størrelse, og
mulighederne inden for rammerne af vores lille "jordsystem" er i sig
selv afhængige af de omgivende systemer, dvs. solsystemet, vores
galakse og i sidste ende hele universet. Det der sker på solen f.ex.
påvirker i høj grad det der sker her på jorden, og solen bliver dermed
en slags tilfældighedsparameter der påvirker vores lille jordsystem på
forskellig måde. Meteorer der rammer jorden vil også påvirke den på
forskellig måde, alt efter størrelse og hvor de rammer. Skulle der
lande nogle ET's fra et fjernt solsystem vil det også påvirke
forholdende på jorden på forskellig måde.

Hvis du til sammenligning har nogle fisk i et beskyttet akvarium
hjemme i stuen, så er mulighederne for variation her uendelig meget
mindre på grund af systemets størrelse og det langt mindre antal af
variabler. Det vil hvis det bliver passet normalt på mange måder blive
ved med at ligne sig selv - fisk og planter vil med tiden formere sig,
de gamle vil dø og nye blive født, men systemet som helhed vil stort
set blive ved med at ligne sig selv. Ikke ret megen variation her,
sålænge der ikke er udefrakommende parametre der griber ind og ændrer
forholdene radikalt.

Med et computerspil gælder de samme regler m.h.t. variation - det
handler som sagt udelukkende om systemets størrelse, hvor effektivt
man udnytter dets muligheder, hvor mange variabler man programmerer
ind til at skabe variation, og hvor mange udefrakommende variabler
(brugerhandlinger) man lader indgå i processen.

Men da systemets størrelse er den primære faktor, og hukommelse og
andre tekniske nødvendigheder koster penge, er begræsningerne jo som
regel af rent økonomisk art. Har man penge nok, kan man jo i
princippet udvide systemet lige så meget som pengene, teknologien og
de fysiske omstændigheder tillader det.

Det er ligesom med alt andet her i livet: har du penge nok så kan
(næsten) alt lade sig gøre. Men penge nok er jo som regel ofte lige
netop det man ikke har... :)


--
Rado

Always listen to experts. They will explain what can't be done
and why. Then do it. - Robert Heinlein

---

"Rado" <rado@fjernpost1.tele.dk> wrote in message
news:afma31574irsop6h0r3od2ftv2c1num0rl@4ax.com...

> Løsningen er såmænd blot at indbygge så mange tilfældighedsparametre i
> programmet og via brugerens valgmuligheder (f.ex. de uundgåelige
> variationer i musens bevægelser når man udfører den samme handling) at
> det er ganske usandsynligt at to brugere nogensinde kommer til at
> opleve helt det samme.

Det er løsningen på at problem som ikke skal løses Meningen er netop at
to brugere oplever det samme landskab når de kigger det samme sted. Pointen
er udelukkende at landskabet kun eksisterer når nogen kigger på det, men det
skal være det samme der ses til hver en tid. Det kan sagtens implementeres.

Hvis der står et bjerg i landskabet og ingen ser det.. står det der så?
Nej... men i samme nu nogen kigger, så er det der.


<snip en masse>
Jeg sætter pris på dit svar, da det viser en interesse, men jeg er bange for
at du misforstår emnet en del.
Meningen er kort fortalt at repræsentere en hel verden ved eksempelvis eet
tal. Det er så kompakt den kan lagres.
Stiger du ind i denne verden og ser på et område, så genereres de synlige
detaljer ud fra fastlagte algoritmer og pseudotilfældige tal, som bruger
"verdenstallet" som seed for den tilfældige sekvens. Den del af verden som
du ser, er detaljeret. Den del du ikek kan se, er grov eller
ikke-eksisterende. Drejer du dig rundt og ser den modsatte vej, så er det
der detaljerne er og bag dig at verden ikke findes.
Det er et krav for troværdigheden at hvis du nu drejer dig tilbage igen, så
ser du det første landskab som det var tidligere. Derfor skal
landskabsgenerationen kunne udføres identisk igen.. derfor psuodotilfældige
tal.

---

"Thomas" <tg@svar.her.ja> writes:

> Mit spørgsmål går på hvorfor disse metoder ikke allerede i stor stil
> er implementeret i spil? Tanken om et meget detaljeret og praktisk
> talt uendeligt stor landskab som man kan gå ind i er da
> fascinerende. Man kan dreje om et hjørne og se ud fra den skov man
> er i, og der ser man et stor bjerg der i ensom majestæt knejser over
> en slette med en flod som snoer sig gennem landskabet. Dette
> landskab og dette bjerg er ikke set af nogen mennesker før. Det
> fandtes end ikke før man så det. Ingen designer har opfundet
> bjerget... man opdager det for første gang.

Jeg troede egentlig at store "rolle-computerspil" allerede havde den
slags tilfældigt landskaber, men jeg må indrømme at jeg ved meget lidt
om emnet. Så vidt jeg kan se er det nye i ROAM at spilleren kan se
helt ud til horisonten uden at landskabet ser fjollet ud.

Der findes en opensource 3d-engine der hedder ogre3d. Så vidt jeg kan
se i deres changelog implementerede de ROAM for nogle år siden, men de
opgav det igen fordi at det krævede for meget CPU-kraft. Jeg ved ikke
hvor indviklet Ogre3d's API er, men måske er kode stadig værd at kigge
på. (Deres site er nede nu, så jeg fandt linket på google cache)

v0.98b (29 March 2002) Changes since 0.97e:

[snip]

Landscape rendering - a ROAM scene manager example implementation is
now included in the distribution, together with an example
demo. Whilst the ROAM approach will not be developed further due to
it's relatively high CPU overhead, it serves as an example of how
vastly different scene managers can be plugged into Ogre.

[snip]

www.ogre3d.com/
www.ogre3d.org/docs/ChangeLog.html
http://64.233.183.104/search?q=cache:www.ogre3d.org/docs/ChangeLog.html

---

"Niels L. Ellegaard" <gnalle@ruc.dk> wrote in message
news:871xaiphyf.fsf@ruc.dk...

> Jeg troede egentlig at store "rolle-computerspil" allerede havde den
> slags tilfældigt landskaber, men jeg må indrømme at jeg ved meget lidt
> om emnet. Så vidt jeg kan se er det nye i ROAM at spilleren kan se
> helt ud til horisonten uden at landskabet ser fjollet ud.

Ikke mig bekendt. Jeg har i hvert fald ofte hørt om hvor meget tid det
kræver for designere at sidde og lave lndskabet.

> Der findes en opensource 3d-engine der hedder ogre3d. Så vidt jeg kan
> se i deres changelog implementerede de ROAM for nogle år siden, men de
> opgav det igen fordi at det krævede for meget CPU-kraft. Jeg ved ikke
> hvor indviklet Ogre3d's API er, men måske er kode stadig værd at kigge
> på. (Deres site er nede nu, så jeg fandt linket på google cache)

Jeg vil kigge på dine links, men jeg tror at de går den anden vej. tager et
komplekst landskab og forenkler det, så det kan gengives hurtigt. Færre
trekanter til grafikkortet. Jeg ønsker istedet at tage noget enkelt..
faktisk bare et enkelt tal, og så lave landskabet derfra.

---

"Thomas" <tg@svar.her.ja> writes:

> Jeg har tidligere postet nedenstående i dk.edb.programering, men der
> diskuterer man tilsyneladende nu kun hvilket sprog der er bedre end hvilket
> andet sprog og hvorfor det er ...*gab*
> Da mit emne som sådan ikke behøver behandles som et programeringsproblem,
> men mere et datalogisk ditto, poster jeg nu også her i håb om lidt response.
>
> Der er sat fut fra det gamle i dk.edb.programmering til videnskab, men jeg
> kan nok desværre ikke splejse de to tråde nu.
>
> Jeg legede for noget tid siden med opbygningen af et landskab i vilkårlig
> detaljegrad ved hjælp af algoritmer som blandt andet ROAM.
> Se evt. http://www.llnl.gov/graphics/ROAM/roam.pdf
> Princippet er simpelt nok. Landskabet er defineret som en række trekanter,
> som kan opdeles til mindre og mindre trekanter, til man har vilkårlig
> detaljegrad. Man behøver kun at have høj opløsning der hvor man er/kigger og
> usete dele af landskabet kan være meget groft opdelt.
>
> Dette muliggører reelt at man kan have et meget stort landskab som
> intetsteds er defineret, før nogen ser på det. I det landskabet ses, da
> opstår det. Opdelingen afhænger af tilfældige afvigelser, som, hvis de er
> pseudotilfældige, vil kunne gendannes præcis fra gang til gang.
>
> Landskaber kan let dannes på denne måde, men andre begreber kan dannes
> tilsvarende. Eksempelvis kan man beregne en sansynlighed for forekomsten af
> skov i et område som en funktion af landskabet på stedet og et andet
> sansynlighedslandskab. Byer, dyreliv og så videre kan genereres dynamisk på
> samme måde.
>
> Mit spørgsmål går på hvorfor disse metoder ikke allerede i stor stil er
> implementeret i spil? Tanken om et meget detaljeret og praktisk talt
> uendeligt stor landskab som man kan gå ind i er da fascinerende. Man kan
> dreje om et hjørne og se ud fra den skov man er i, og der ser man et stor
> bjerg der i ensom majestæt knejser over en slette med en flod som snoer sig
> gennem landskabet. Dette landskab og dette bjerg er ikke set af nogen
> mennesker før. Det fandtes end ikke før man så det. Ingen designer har
> opfundet bjerget... man opdager det for første gang.
> Kommer en anden dagen efter, så ses samme bjerg på samme sted, da der om
> sagt er tale om pseudotilfældige tal med seeds, der gør at når samme
> landskab beregnes igen, så kommer man til samme resultat.
>
> Er der nogen her som har indsigt i problemstillinger som umuliggører dette i
> praksis? Jeg har fra eksperimenter selv at set de skiterede metoder sagtens
> kan lave detaljerede landskaber, som kan være ganske store.

Mange strategispil bruger tilfældigt genererede landkort, men som
regel har de en begrænset størrelse og detaljerigdom.

Jeg har selv lavet et program, der laver et planetlandkort med
mulighed for næsten ubegrænset zoom (dog kun for højder, der kommer
ikke detaljer som træer eller huse, når man zoomer ind til
meterskala). Jeg har dog set programmer, der med skiftende held
forsøger også at kunne zoome ind til denne skala.

Men en af problemerne med ubegrænsede landskaber i computerspil er, at
selv om man kan lave disse kæmpestore landskaber, så ligner de
forskellige dele af landskabet stort set hinanden -- programmerne er
ikke gode nok til at skabe reel variation, dvs. bjerge eller skove, der
ikke bare er variationer over samme tema. Endvidere er programmerne
sjældent gode til at få de forskellige detaljer til at spille sammen.
F.eks. bør vegetationen ændres i forhold til vindretning, nedbør osv.,
som afhænger af det omgivende landskab. Selv det at lægge realistiske
flodforløb ind i et rekursivt genereret landskab er et særdeles
vanskeligt problem, specielt hvis man ikke kan lagre hele landskabet
på en gang med en rimelig detaljegrad.

> Jeg overvejer at lave bachelorprojekt om det i datalogi om ikke så
> længe,

Hvis det er på DIKU, vil jeg da gerne være vejleder.

> men ville lige udsende en føler først. Teknologien virker nærmest grænseløs
> (indenfor opløsningen af talsystemerne i moderne computere), men alligevel
> er den ikke anvendt, som i mit eksempel. Hvorfor ikke? Fordi der er for lidt
> kontrol med landskabet, og moderne spil kræver garanti for spændende
> landskaber med spændende opgaver rundt om hvert et hjørne? Man skulle da tro
> at der ville være et marked for en verden der var tilfældig og hvor man
> vitterlig kunne drage på opdagelse. Selv at ændre denne verden kan gøres. Så
> skal indformation om ændringen naturligvis lagres, men selv store ændringer
> kunne lagres ved få værdier. Eksempel: jeg udløser en kraftig eksplosion et
> sted. Den har en effekt på omgivelserne. Denne effekt skal ikke lagres. Når
> eksplosionen sker så knyttes et stort tilfældigt tl til den og anvendes som
> seed for beregningerne af ændringer i landskabet som følge af eksplosionen.
> Jeg kan nu se hullet, og landskabet er ændret. Positionen og det anvendte
> "seed" lagres. Næste person der nærmer sig vil forårsage at effekten
> genskabes ud fra de få lagrede værdier.

Det kan virke i et vist omfang, men ændringer i landskabet kan nemt
ophobe sig, sådan at det er urealistisk at gemme dem alle. Desuden
forudsætter din ide, at man i nogen grad kan forudsige konsekvensen af
en given ændring af seed.

Torben

---

> Jeg har selv lavet et program, der laver et planetlandkort med
> mulighed for næsten ubegrænset zoom (dog kun for højder, der kommer
> ikke detaljer som træer eller huse, når man zoomer ind til
> meterskala). Jeg har dog set programmer, der med skiftende held
> forsøger også at kunne zoome ind til denne skala.

Ja, det er sådan noget jeg taler om. Beregnede du dynamisk opløsning, sådan
at bagsiden af planeten var grov mens den nære forside var fin, eller gik du
bare amok med trekanterne?

> Men en af problemerne med ubegrænsede landskaber i computerspil er, at
> selv om man kan lave disse kæmpestore landskaber, så ligner de
> forskellige dele af landskabet stort set hinanden -- programmerne er
> ikke gode nok til at skabe reel variation, dvs. bjerge eller skove, der
> ikke bare er variationer over samme tema.

Det forstår jeg så ikke helt. Nu var mine eksempler godt nok kun mindre
landområder som jeg byggede detaljer på, men jeg kunne sagtens opnå
vilkårligt varierede landskaber, og det endda uden at putte errorsion og
ligende ind i det, hvilket bør være muligt.


> Endvidere er programmerne
> sjældent gode til at få de forskellige detaljer til at spille sammen.
> F.eks. bør vegetationen ændres i forhold til vindretning, nedbør osv.,
> som afhænger af det omgivende landskab. Selv det at lægge realistiske
> flodforløb ind i et rekursivt genereret landskab er et særdeles
> vanskeligt problem, specielt hvis man ikke kan lagre hele landskabet
> på en gang med en rimelig detaljegrad.

Ja, det er kompliceret, men , så vidt jeg kan se, ikke umuligt. Du kan
beregne typisk vejr i et landskab baseret på meget simple modeller. Den side
af bjergene som vender mod vandet er våd og den anden er tør etc.
Med hensyn til floderne, så eksperiementerede jeg med det en overgang. Nu
husker jeg ikke algoritmen eller dens navn helt præcist længere, men ideen
var netop at man startede med at dele landskabet i meget store trekanter.
Løb floden ud af en trekants side (et udefineret sted på siden), så blev
siden opdelt igen og igen til man havde det præcise forløb. Denne metode vil
netop være velegnet til dynamisk opløsning. Man behøver ikke at vide hvor
floden præcist løber, når man ikke ser på den. Den er der bare et sted. Når
man kigger, så finder man ud af præcis hvor.


> Det kan virke i et vist omfang, men ændringer i landskabet kan nemt
> ophobe sig, sådan at det er urealistisk at gemme dem alle. Desuden
> forudsætter din ide, at man i nogen grad kan forudsige konsekvensen af
> en given ændring af seed.

Hvis vi siger at der over en periode er en milion personer i denne verden
som laver tusinde ændringer, så er det reelt stadig en lille datamængde, der
er tale om. Visse ændringer kan også forsvinde med tiden.
Jeg forstår ikke hvad du mener med at man skal forudsige konsekvensen af et
givent seed.
Hvis jeg laver den nævnte eksplosion så forestillede jeg mig at det foregik
ved at definere den som.. et seed, en størelse og en position. Effekten af
eksplosionen kommer som resultat fre en eksplosions-funktion der deformerer
landskabet på en eksplosionsagtig måde givet det seed. Seed skal kun sikre
at ikke alle eksplosioner er ens.

Nu er du jo selv inde på diku og fungerer vel somme tider som vejleder (?),
så du er i rette position til at besvare spørgsmålet om dette vil være et
velegnet bachelorprojekt. Jeg har en del mere udvikler-erfaring end den
gennemsnitlige studerende så jeg tvivler ikke på at jeg kan implementere
det, hvis ellers metoderne er sunde nok. Vil det være relevant som projekt,
tror du?

---

"Thomas" <tg@svar.her.ja> writes:

> > Jeg har selv lavet et program, der laver et planetlandkort med
> > mulighed for næsten ubegrænset zoom (dog kun for højder, der kommer
> > ikke detaljer som træer eller huse, når man zoomer ind til
> > meterskala). Jeg har dog set programmer, der med skiftende held
> > forsøger også at kunne zoome ind til denne skala.
>
> Ja, det er sådan noget jeg taler om. Beregnede du dynamisk opløsning, sådan
> at bagsiden af planeten var grov mens den nære forside var fin, eller gik du
> bare amok med trekanterne?

Jeg laver landkortprojektioner af forskellig art og regner baglæns fra
et punkt på kortet til et punkt på globen. Dermed genererer jeg kun
data for de punkter, der rent faktisk er synlige på kortet. Jeg
genererede ikke trekanter, men det kunne man godt, hvis man ville lave
3D rendering. Hvis du vil se programmet, kan du hente det på min
hjemmeside (http://www.diku.dk/~torbenm). Bare lad vær med at kigge i
koden, den er ret grim som resultat af utallige småændringer gennem
flere årtier (det begyndte som et program til min BBC micro).

Hvis jeg skulle lave et landskab set fra en figur på eller nær
overfladen, så ville jeg nok lave modsat snoede logaritmiske spiraler
og generere data, der hvor de krydser (se
http://ccins.camosun.bc.ca/~jbritton/fibslide/fib30.gif). Dermed vil
områder nær personen blive genereret med flere detaljer end fjerne
dele af landskabet.

> > Men en af problemerne med ubegrænsede landskaber i computerspil er, at
> > selv om man kan lave disse kæmpestore landskaber, så ligner de
> > forskellige dele af landskabet stort set hinanden -- programmerne er
> > ikke gode nok til at skabe reel variation, dvs. bjerge eller skove, der
> > ikke bare er variationer over samme tema.
>
> Det forstår jeg så ikke helt. Nu var mine eksempler godt nok kun mindre
> landområder som jeg byggede detaljer på, men jeg kunne sagtens opnå
> vilkårligt varierede landskaber, og det endda uden at putte errorsion og
> ligende ind i det, hvilket bør være muligt.

Erosion er svær, hvis man ikke genererer hele landskabet på en gang og
simulerer vejrsystemer osv.

> > Endvidere er programmerne
> > sjældent gode til at få de forskellige detaljer til at spille sammen.
> > F.eks. bør vegetationen ændres i forhold til vindretning, nedbør osv.,
> > som afhænger af det omgivende landskab. Selv det at lægge realistiske
> > flodforløb ind i et rekursivt genereret landskab er et særdeles
> > vanskeligt problem, specielt hvis man ikke kan lagre hele landskabet
> > på en gang med en rimelig detaljegrad.
>
> Ja, det er kompliceret, men , så vidt jeg kan se, ikke umuligt. Du kan
> beregne typisk vejr i et landskab baseret på meget simple modeller. Den side
> af bjergene som vender mod vandet er våd og den anden er tør etc.

Det er mere vindretening end hvor vandet er, der har betydning. Men
uanset hvad, så kræver klimaet ikek-lokal information, hvilket
vanskeliggør generering af mindre dele af landskabet isoleret fra
resten.

> Med hensyn til floderne, så eksperiementerede jeg med det en overgang. Nu
> husker jeg ikke algoritmen eller dens navn helt præcist længere, men ideen
> var netop at man startede med at dele landskabet i meget store trekanter.
> Løb floden ud af en trekants side (et udefineret sted på siden), så blev
> siden opdelt igen og igen til man havde det præcise forløb. Denne metode vil
> netop være velegnet til dynamisk opløsning. Man behøver ikke at vide hvor
> floden præcist løber, når man ikke ser på den. Den er der bare et sted. Når
> man kigger, så finder man ud af præcis hvor.

Men man skal dog have en kilde af vand til floden. Hvis man ikke har
genereret bjerget, ved man ikke om man skal have en flod til at
afvande den. Men du har ret i, at man ikke behøver så fine detaljer
om andre dele af landskabet.

> > Det kan virke i et vist omfang, men ændringer i landskabet kan nemt
> > ophobe sig, sådan at det er urealistisk at gemme dem alle. Desuden
> > forudsætter din ide, at man i nogen grad kan forudsige konsekvensen af
> > en given ændring af seed.
>
> Hvis vi siger at der over en periode er en milion personer i denne verden
> som laver tusinde ændringer, så er det reelt stadig en lille datamængde, der
> er tale om. Visse ændringer kan også forsvinde med tiden.

Ja, jeg har set denne ide i computerrollespil: Når man kommer ind i et
level, genereres nye monstre tilfældigt, men de bliver husket sålænge
man er på dette level. Hvis man kortvarigt forlader dette level,
huskes monstrene til man vender tilbage, men hvis man er vek i længere
tid, glemmes det. Det samme gælder status om hvilke døre, der er åbne
og hvilke fælder, der er desarmerede (og hvilke mure, der er lavet
huller igennem). Ikke ideelt, men det kan bortforklares med, at der
kommer nogen og genopbygger status quo mens man er væk.

> Jeg forstår ikke hvad du mener med at man skal forudsige konsekvensen af et
> givent seed.
> Hvis jeg laver den nævnte eksplosion så forestillede jeg mig at det foregik
> ved at definere den som.. et seed, en størelse og en position. Effekten af
> eksplosionen kommer som resultat fre en eksplosions-funktion der deformerer
> landskabet på en eksplosionsagtig måde givet det seed. Seed skal kun sikre
> at ikke alle eksplosioner er ens.

O.K, jeg tror jeg ved, hvor du vil hen. Det kan nok godt lade sig
gøre.

> Nu er du jo selv inde på diku og fungerer vel somme tider som vejleder (?),
> så du er i rette position til at besvare spørgsmålet om dette vil være et
> velegnet bachelorprojekt. Jeg har en del mere udvikler-erfaring end den
> gennemsnitlige studerende så jeg tvivler ikke på at jeg kan implementere
> det, hvis ellers metoderne er sunde nok. Vil det være relevant som projekt,
> tror du?

Ja da. Jeg har tidligere vejledt et projekt om autogenerering i
computerspil.

Torben

---

> Erosion er svær, hvis man ikke genererer hele landskabet på en gang og
> simulerer vejrsystemer osv.

Ja. Jeg tror jeg måske ikke forklarede mig helt godt. Jeg vil ikke beregne
erosion for overfladen før man faktisk ser overfladen. Den simple type med
en vis mængde nedbør som fører til opløsning af jord med strømning til
naboområder med opløsning og/eller aflejring, burde kunne gøres i baggrunden
mens man nærmer sig et område. Helt realtime bliver det nok svært at gøre
det.
Grovere metoder som at definere et landskab som værende mere eller mindre
afrundet, kan indbygges i selve landskabsgenereringen. Den del der i
forvejen skal beregne højdekortet. Det er et spørgsmål om filtreting.

> Det er mere vindretening end hvor vandet er, der har betydning. Men
> uanset hvad, så kræver klimaet ikek-lokal information, hvilket
> vanskeliggør generering af mindre dele af landskabet isoleret fra
> resten.

Korrekt, men jeg vil mene at man kan lave et overordnet vindkort, som kan
gøres mere detaljeret på samme måde som landskabet. Man kan dermed starte
med at se på et helt kontinent og dettes overordnede vindmønster. Når
detaljerne skal bruges, så beregnes landdetaljer og også yderligere
vindmønstre. Man kan lade vind_1 afhænge af land_1 og vind_0, så yderligere
detaljer som eksempelvis bjerge vil medføre andre strømningsmønstre. Vil du
ikke mene at det er en mulighed?
Meteologisk korrekte bliver disse simulationer ikke, men det giver mulighed
for at definere forskellige områder med forskelligt nedbør og vindretning.

> Ja da. Jeg har tidligere vejledt et projekt om autogenerering i
> computerspil.

Det kan være jeg kommer og banker på din dør en dag
Har du et link til projektet hvis det er offentligt tilgængeligt?

---

"Thomas" <tg@svar.her.ja> writes:

> > Erosion er svær, hvis man ikke genererer hele landskabet på en gang og
> > simulerer vejrsystemer osv.
>
> Ja. Jeg tror jeg måske ikke forklarede mig helt godt. Jeg vil ikke beregne
> erosion for overfladen før man faktisk ser overfladen. Den simple type med
> en vis mængde nedbør som fører til opløsning af jord med strømning til
> naboområder med opløsning og/eller aflejring, burde kunne gøres i baggrunden
> mens man nærmer sig et område. Helt realtime bliver det nok svært at gøre
> det.
> Grovere metoder som at definere et landskab som værende mere eller mindre
> afrundet, kan indbygges i selve landskabsgenereringen. Den del der i
> forvejen skal beregne højdekortet. Det er et spørgsmål om filtreting.
>
> > Det er mere vindretening end hvor vandet er, der har betydning. Men
> > uanset hvad, så kræver klimaet ikek-lokal information, hvilket
> > vanskeliggør generering af mindre dele af landskabet isoleret fra
> > resten.
>
> Korrekt, men jeg vil mene at man kan lave et overordnet vindkort, som kan
> gøres mere detaljeret på samme måde som landskabet. Man kan dermed starte
> med at se på et helt kontinent og dettes overordnede vindmønster. Når
> detaljerne skal bruges, så beregnes landdetaljer og også yderligere
> vindmønstre. Man kan lade vind_1 afhænge af land_1 og vind_0, så yderligere
> detaljer som eksempelvis bjerge vil medføre andre strømningsmønstre. Vil du
> ikke mene at det er en mulighed?

Jo, det lyder plausibelt.

> Meteologisk korrekte bliver disse simulationer ikke, men det giver mulighed
> for at definere forskellige områder med forskelligt nedbør og vindretning.
>
> > Ja da. Jeg har tidligere vejledt et projekt om autogenerering i
> > computerspil.
>
> Det kan være jeg kommer og banker på din dør en dag
> Har du et link til projektet hvis det er offentligt tilgængeligt?

Det er ikke tilgængeligt på webben, men du kan da godt låne det. Det
har dog et noget andet fokus end dit forslag.

Torben

---

Thomas wrote:

> Dette muliggører reelt at man kan have et meget stort landskab
> som intetsteds er defineret, før nogen ser på det. I det
> landskabet ses, da opstår det. Opdelingen afhænger af
> tilfældige afvigelser, som, hvis de er pseudotilfældige, vil
> kunne gendannes præcis fra gang til gang.

Det gamle spil "Elite" (rumspil fra 64'er tiden) bruger så vidt jeg kan
regne ud netop den metode der. Der var en masse planeter man kunne rejse
imellem, som hver havde tilknyttet en mængde detaljer som koordinater og
navn og størrelse osv. Disse detaljer udgjorde en samlet datamængde der var
langt større end der kunne indeholdes i de få kilobytes RAM der var i
computeren. Jeg lagde mærke til at alle navnene var 2, 4, 6 eller 8 tegn
lange, og de alle bestod af blokke på 2 bogstaver, hvor det ene var en
konsonant og det andet en vokal. De var sikkert genereret af en seeded
randomgenerator og nogle få regler eller tabelopslag. De andre detaljer var
sikkert også lavet på den måde.

--
Ulrik Smed
Aarhus, Denmark

---

> Det gamle spil "Elite" (rumspil fra 64'er tiden) bruger så vidt jeg kan
> regne ud netop den metode der. Der var en masse planeter man kunne rejse
> imellem, som hver havde tilknyttet en mængde detaljer som koordinater og
> navn og størrelse osv. Disse detaljer udgjorde en samlet datamængde der
> var
> langt større end der kunne indeholdes i de få kilobytes RAM der var i
> computeren. Jeg lagde mærke til at alle navnene var 2, 4, 6 eller 8 tegn
> lange, og de alle bestod af blokke på 2 bogstaver, hvor det ene var en
> konsonant og det andet en vokal. De var sikkert genereret af en seeded
> randomgenerator og nogle få regler eller tabelopslag. De andre detaljer
> var
> sikkert også lavet på den måde.

Ja, det lyder egentlig sansynligt. Der blev dog kun lavet ting som nogle
kontakter, handler etc for hver planet?
Det er dog samme grundide, ja.

---

Thomas wrote:

> Ja, det lyder egentlig sansynligt. Der blev dog kun lavet ting
> som nogle kontakter, handler etc for hver planet?

Der var et lager af forkellige varer man kunne købe og sælge på hver planet,
med tilhørende prisliste. Disse data var dynamiske, ændrede sig når man
handlede, men jeg ved ikke om de opdaterede lagerlister blev gemt eksakt til
næste gang man kom til samme planet. Det ville være svært at lave med en
randomgenerator, for man kan jo ikke lige finde et seed der giver lige netop
den opdaterede liste som resultat. Det er nok det Torben hentyder til når
han siger man skal kunne forudsige konsekvensen af ændringer af seed. I det
tilfælde her er det så ikke bare i nogen grad, men helt eksakt, hvis
listerne skal passe. Så skulle man genererer en formel der skabte den nye
liste, i stil med JPG komprimering (hvis jeg ellers har forstået JPG
nogenlunde korrekt).

--
Ulrik Smed
Aarhus, Denmark

---

"Ulrik Smed" <ulsm@post1.tele.dk> wrote in message
news:4235ee60$0$270$edfadb0f@dread12.news.tele.dk...

> Det ville være svært at lave med en
> randomgenerator, for man kan jo ikke lige finde et seed der giver lige
> netop
> den opdaterede liste som resultat.

Nej, hvis du lander, ser varer og priser, handler og de ændrer sig, så vil
man vanskeligt kunne lade markedet være defineret med et seed til næste
gang. Man kan imidlertid lade grundmarkedet defineres som et seed (antager
at markedet vil være større end et seed), og så lagre de handler der er
foretaget. Dermed kan man hver gang gendanne grundmarkedet og efterfølgende
gennemføre de foregående handler og det resulterende marked er det du forlod
efter sidste besøg.
Dermed skal du lagre et sed som bruges til at definere udgangspunktet,
ligesom i et landskab, og dertil lagre de ændringer der er foretaget. At du
eksempelvis har købt 100t skruer.

> Så skulle man genererer en formel der skabte den nye
> liste, i stil med JPG komprimering (hvis jeg ellers har forstået JPG
> nogenlunde korrekt).

Der er ikke noget tilfældigt ved jpeg. Det er opsplitning i blokke og disses
frekvenser, derefter minskes nogle frekvenser mere end andre. Til slut
komprimeres frekvensrepræsentationen.

---

Ulrik Smed wrote:
> Der var et lager af forkellige varer man kunne købe og sælge på hver
> planet, med tilhørende prisliste. Disse data var dynamiske, ændrede sig
> når man handlede, men jeg ved ikke om de opdaterede lagerlister blev gemt
> eksakt til næste gang man kom til samme planet.

Så vidt jeg husker så bevægede priserne sig imod en ligevægt efter et
stykke tid, så det mest hensigtsmæssige var at flyve lidt længere ruter
end blot frem og tilbage, således at man fik størrer profit.

Men det kan jo være at de kun huskede f.eks. de sidste 10-20 planeter,
og resten var random.

Jeg lider stadig af aversioner mod "An der schöne blaue donau", efter
at havde hørt på Amstrad 464 versionen i ugevis.

--
Mvh. Carsten Svaneborg
http://gauss.ffii.org

---

Carsten Svaneborg <zqex@sted.i.tyskland.de> writes:

> Ulrik Smed wrote:
> > Der var et lager af forkellige varer man kunne købe og sælge på hver
> > planet, med tilhørende prisliste. Disse data var dynamiske, ændrede sig
> > når man handlede, men jeg ved ikke om de opdaterede lagerlister blev gemt
> > eksakt til næste gang man kom til samme planet.
>
> Så vidt jeg husker så bevægede priserne sig imod en ligevægt efter et
> stykke tid, så det mest hensigtsmæssige var at flyve lidt længere ruter
> end blot frem og tilbage, således at man fik størrer profit.
>
> Men det kan jo være at de kun huskede f.eks. de sidste 10-20 planeter,
> og resten var random.

I den oprindelige Elite varierede priserne nærmest tilfældigt uden
hensyntagen til afstande, men med hensyntagen til planetens type:
Industrial gav lavere priser for tekniske pordukter men højere for
naturlige, mens agricultural var omvendt. Teknologiniveauet havde
også betydning for priserne, og regeringstypen havde indflydelse på,
hvor meget priserne varierede (anarkistiske planeter havde f.eks. mere
variationer i priserne end demokratiske).

En taktik, jeg brugte, var at finde en agricultural og en industrial
planet, der er så tætte på hinanden, at man kan flyve flere gange frem
og tilbage på en ladning brændstof. Så ville jeg hoppe frem og
tilbage indtil priserne så O.K. ud (eller jeg kun havde et hop
tilbage, som jeg kunne bruge til at undslippe overmagt eller witch
space). Her fremgik det tydeligt, at priserne ikke havde hukommelse,
da de nemt kunne variere meget mellem to hop.

Spillet var klart forud for sin tid. Hvem andre havde i 1984 ægte 3D
grafik i realtime? Og så på en 2MHz 8-bit computer?

Jeg fandt iøvrigt BBC-micro versionen bedre end de fleste
konkurrenter, da den var lavet til BBC-microens analoge joystikport,
hvilket gav bedre finkontrol end f.eks. C64's nipositionsjoystick.

Den ene af forfatterne (Ian Bell) til det oprindelige Elite har
iøvrigt en god side om spillet: http://www.iancgbell.clara.net/elite/
Artiklen fra Guardian
(http://www.guardian.co.uk/weekend/story/0,3605,1064107,00.html), som
Bell's side refererer til er iøvrigt ganske underholdende.

Torben

---

Torben Ægidius Mogensen wrote:

> Spillet var klart forud for sin tid. Hvem andre havde i 1984
> ægte 3D grafik i realtime? Og så på en 2MHz 8-bit computer?

Selv på 64'eren på 1MHz kørte det faktisk godt. Der var endda frådset med
grafikken ved at solene var udfyldte og med flotte 'flammer' i kanten. Jeg
har vist desværre ikke set BBC-versionen.

> Jeg fandt iøvrigt BBC-micro versionen bedre end de fleste
> konkurrenter, da den var lavet til BBC-microens analoge
> joystikport, hvilket gav bedre finkontrol end f.eks. C64's
> nipositionsjoystick.

Jeg spillede altid på tastaturet i det spil. Der var jo en del andre
funktioner end lige retninger og skyd, så var det træls at skulle flytte
hænderne. Mit 'joystick' bestod af et hjemmelavet brædt med 5 knapper, som
var kanon at styre med, men krævede begge hænder.

--
Ulrik Smed
Aarhus, Denmark

---

"Ulrik Smed" <ulsm@post1.tele.dk> writes:

> Torben Ægidius Mogensen wrote:
>
> > Spillet var klart forud for sin tid. Hvem andre havde i 1984
> > ægte 3D grafik i realtime? Og så på en 2MHz 8-bit computer?
>
> Selv på 64'eren på 1MHz kørte det faktisk godt. Der var endda frådset med
> grafikken ved at solene var udfyldte og med flotte 'flammer' i kanten. Jeg
> har vist desværre ikke set BBC-versionen.

Samme effekt fandtes i BBC versionen.

> > Jeg fandt iøvrigt BBC-micro versionen bedre end de fleste
> > konkurrenter, da den var lavet til BBC-microens analoge
> > joystikport, hvilket gav bedre finkontrol end f.eks. C64's
> > nipositionsjoystick.
>
> Jeg spillede altid på tastaturet i det spil. Der var jo en del andre
> funktioner end lige retninger og skyd, så var det træls at skulle flytte
> hænderne. Mit 'joystick' bestod af et hjemmelavet brædt med 5 knapper, som
> var kanon at styre med, men krævede begge hænder.

Jeg fandt det ikke noget problem at bruge taster en gang imellem, mens
jeg brugte joystick det meste af tiden. Og jeg fandt et smart trick
med joysticken: Når jeg så ud gennem "bagruden", vendte jeg joysticken
om, og havde dermed styring, der reagerede ligesom når man ser ud af
"forruden".

Specielt dokning var meget lettere med en analog joystick: Man skulle
bare slå autocentrering fra, så kunne man nemt finde lige den
rotationshastighed, der passede til stationen.

Torben

---

Torben Ægidius Mogensen wrote:

> Jeg fandt det ikke noget problem at bruge taster en gang
> imellem, mens jeg brugte joystick det meste af tiden. Og jeg
> fandt et smart trick med joysticken: Når jeg så ud gennem
> "bagruden", vendte jeg joysticken om, og havde dermed styring,
> der reagerede ligesom når man ser ud af "forruden".

Hehe, snyd!

> Specielt dokning var meget lettere med en analog joystick: Man
> skulle bare slå autocentrering fra, så kunne man nemt finde
> lige den rotationshastighed, der passede til stationen.

Smart nok. Jeg tror nok jeg bare placerede mig så lige jeg kunne ud
for hullet, uden at forsøge at rotere med rundt, og så fløj ind når hullet
var lige før vandret. Brugte side-view til at standse det rigtige sted når
jeg linede op, og roterede så 90 grader og lavede et 90 graders pull-up.
Havde man fået sparet op til en dockingcomputer, var det jo ingen sag. Men
den roterede ens rumskib med rundt når den landede, mener jeg. Denne
simulerede dockingcomputer var egentlig også en lille programmeringsperle i
sig selv. Hehe, man får lidt lyst til at prøve igen, på "Vice" C-64
emulatoren.

Kom forresten i tanke om et 3D spil som vist var fra før Elite kom, det var
3D-Combat Zone til Spectrum. Hastigheden var måske ikke lige værdig til at
blive kaldt 'real-time'...

--
Ulrik Smed
Aarhus, Denmark

---

"Ulrik Smed" <ulsm@post1.tele.dk> writes:

> Thomas wrote:
>
> > Dette muliggører reelt at man kan have et meget stort landskab
> > som intetsteds er defineret, før nogen ser på det. I det
> > landskabet ses, da opstår det. Opdelingen afhænger af
> > tilfældige afvigelser, som, hvis de er pseudotilfældige, vil
> > kunne gendannes præcis fra gang til gang.
>
> Det gamle spil "Elite" (rumspil fra 64'er tiden)

Rettelse: Fra BBC-micro tiden og senere portet til bl.a. C64.

> bruger så vidt jeg kan
> regne ud netop den metode der. Der var en masse planeter man kunne rejse
> imellem, som hver havde tilknyttet en mængde detaljer som koordinater og
> navn og størrelse osv. Disse detaljer udgjorde en samlet datamængde der var
> langt større end der kunne indeholdes i de få kilobytes RAM der var i
> computeren. Jeg lagde mærke til at alle navnene var 2, 4, 6 eller 8 tegn
> lange, og de alle bestod af blokke på 2 bogstaver, hvor det ene var en
> konsonant og det andet en vokal. De var sikkert genereret af en seeded
> randomgenerator og nogle få regler eller tabelopslag. De andre detaljer var
> sikkert også lavet på den måde.

Ja, jeg har set en artikel om nogle, der portede Elite til Archimedes.
De kunne ganske enkelt ikke gennemskue den kode (i 6502 assembler),
der genererede planetdata, så de endte med at lave en 6502 emulator,
der kørte den oprindelige kode.

Torben

---

Torben Ægidius Mogensen wrote:
> "Ulrik Smed" <ulsm@post1.tele.dk> writes:

>> Det gamle spil "Elite" (rumspil fra 64'er tiden)
>
> Rettelse: Fra BBC-micro tiden og senere portet til bl.a. C64.

Hehe, jeg er nok ikke den eneste her der har brugt en del timer på det spil!
Tak for rettelsen, vidste faktisk ikke det var fra BBC'en, er ellers
selv gammel Acorn/Archimedes-fan.

> Ja, jeg har set en artikel om nogle, der portede Elite til
> Archimedes. De kunne ganske enkelt ikke gennemskue den kode (i
> 6502 assembler), der genererede planetdata, så de endte med at
> lave en 6502 emulator, der kørte den oprindelige kode.

Fedt! I bedste Mame-stil! Har vist faktisk selv en C-64 emulator til
Archimedes, kan være den er bygget over denne emulator. Der er forresten en
BBC-emulator til Archimedes som vist endda hedder noget med 6502, det er
måske netop den.

--
Ulrik Smed
Aarhus, Denmark

---

"Ulrik Smed" <ulsm@post1.tele.dk> writes:

> Torben Ægidius Mogensen wrote:
> > "Ulrik Smed" <ulsm@post1.tele.dk> writes:
>
> >> Det gamle spil "Elite" (rumspil fra 64'er tiden)
> >
> > Rettelse: Fra BBC-micro tiden og senere portet til bl.a. C64.
>
> Hehe, jeg er nok ikke den eneste her der har brugt en del timer på det spil!
> Tak for rettelsen, vidste faktisk ikke det var fra BBC'en, er ellers
> selv gammel Acorn/Archimedes-fan.
>
> > Ja, jeg har set en artikel om nogle, der portede Elite til
> > Archimedes. De kunne ganske enkelt ikke gennemskue den kode (i
> > 6502 assembler), der genererede planetdata, så de endte med at
> > lave en 6502 emulator, der kørte den oprindelige kode.
>
> Fedt! I bedste Mame-stil! Har vist faktisk selv en C-64 emulator til
> Archimedes, kan være den er bygget over denne emulator. Der er forresten en
> BBC-emulator til Archimedes som vist endda hedder noget med 6502, det er
> måske netop den.

6502 emulatoren på Archimedes blev lavet af Acorn selv, for at gøre
det muligt at køre BBC-micro programmer på Archimedes. Emulatoren
kunne dog ikke køre Elite, da denne lavede noget fusk med videochippen
for at have en skærm mode (s/h højopløsning) øverst på skærmen og en
anden (fire farver, lav opløsning) nederst. Det kunne emulatoren af
en eller anden grund ikke klare.

Der var heller ikke joystickport til Archimedes (det blev nok anset
for overflødigt, når der var en mus), så et emuleret Elite ville
alligevel kun kunne spilles med tastaturkontrol. Archimedes Elite
forsøgte at bruge musen til styring, men det fungerede efter min
mening ikke nær så godt som en joystick.

Den emulator, der blev brugt i Archimedes Elite, var noget mere
primitiv, da den kun skulle emulere en delmængde af instruktionerne og
ikke noget af BBC microens hardware.

Torben