Vinnaren i pepparkakshustävlingen!
  • 1
  • 2
2017-12-05, 17:23
  #13
Medlem
4yoonlys avatar
Citat:
Ursprungligen postat av sommarlov
Var kanske lite otydlig.

Under Windows 95/98 skrev spelen direkt till hårdvara, för prestandans skull.
Dessa spel funkar inte under Windows XP eller nyare då de själva hanterar hårdvaran.

Jag förstår nog ändå inte riktigt vad som du anser var:

Citat:
Det är inte helt korrekt.

Windows kunde förövrigt (nästan OS2 likt i vissa fall, som Microsoft var del i även det) köra en del hårdvaru pokeande spel... OK inte under Windows i sig, men tillsammans med det. Sedan fanns det även spel som faktiskt hade stöd för Windows... Även om detta inte var något jag nämnde/sade i mitt inlägg.

Under Windows XP var det givetvis svårare då XP kerneln startade och DOS var mer eller mindre en emulation. W95/98 var mer ett utbryt ifrån "DOS" och kunde därmed "encapsulate" det med ett fönster typ.

Hur som helst, OSet var inte något jag ens nämnde i inlägget du svarade på...

Du får poängtera och quota dom felen jag skrev i inlägget du svarade på så kan jag se vad du menar och i sådana fall vad jag skrev fel...
Citera
2017-12-05, 18:56
  #14
Medlem
Okej, om vi säger att man kunde göra ett operativsystem med dagens programmeringsspråk och kunskap för dåtidens hårdvara. Hade man kunnat få ut mer kräm då?

Så verkar det ju vara.
Men detta stämmer alltså inte riktigt då dåtidens OS begränsade?
Har jag förstått det rätt?
Citera
2017-12-05, 19:08
  #15
Medlem
Precis som hårdvaran blivit med sofistikerad över åren har också mjukvaran blivit det. För 20 år sedan var spelindustrin knappt en industri, många spel utvecklades av en handfull personer.

Dagens utvecklingsverktyg skulle nog ha svårt att köra på 20 år gammal hårdvara men själva knowhow skulle funka. Sedan har väl en del kunskap gått förlorad också, tex hur man optimerar mote en specifik platform.

Om man skulle sätta nån av de ledande utvecklarna, tex Dice att jobba med nån gammal platform skulle dom nog kunna producera något som skulle varit top notch för 20 år sedan.
Citera
2017-12-05, 23:48
  #16
Moderator
Neksnors avatar
Har sett några nördiga grafikdemo som lyckats skrämma ut förvånansvärt mycket ur gamla datorer. Har för mig att det handlar om kod som mer eller mindre specialskrivits på låg nivå för just den aktuella hårdvaran.
Citera
2017-12-11, 12:52
  #17
Medlem
4yoonlys avatar
Citat:
Ursprungligen postat av 51mon
Precis som hårdvaran blivit med sofistikerad över åren har också mjukvaran blivit det. För 20 år sedan var spelindustrin knappt en industri, många spel utvecklades av en handfull personer.

Dagens utvecklingsverktyg skulle nog ha svårt att köra på 20 år gammal hårdvara men själva knowhow skulle funka. Sedan har väl en del kunskap gått förlorad också, tex hur man optimerar mote en specifik platform.

Om man skulle sätta nån av de ledande utvecklarna, tex Dice att jobba med nån gammal platform skulle dom nog kunna producera något som skulle varit top notch för 20 år sedan.

Då får nog gå tillbaka lite längre än 20 år dock, spelindustrin fanns och tjänade mycket pengar på 80 talet till och med.

Dice gjorde ett väldigt roligt (kanske inte banbrytande dock) pinball spel på Amigan. Det var väldigt bra grafik, väldigt bra ljud/musik och väldigt "polished" så det var riktigt roligt att spela... De gamla rävarna i Dice (om dom finns kvar dvs) är ju gamla demo gubbar och förstår vad det innebär att jobba närmare hårdvaran och det var säkerligen dessa som tyckte Mantle var en bra grej som ex. (skulle inte förvåna mig om dom var en del av det...)
Citera
2018-01-15, 00:03
  #18
Medlem
sonny crockets avatar
Citat:
Ursprungligen postat av Neksnor
Har sett några nördiga grafikdemo som lyckats skrämma ut förvånansvärt mycket ur gamla datorer. Har för mig att det handlar om kod som mer eller mindre specialskrivits på låg nivå för just den aktuella hårdvaran.
Om man kan göra såhär med en commodore 64, vad kan man då inte göra med en pc från -97?
https://www.youtube.com/watch?v=Plu64YncTp8
se också https://www.youtube.com/results?search_query=c64+demo
Citera
2018-01-20, 15:53
  #19
Moderator
impieteers avatar
Citat:
Ursprungligen postat av Aragonkommer
Vi säger att någon fick i uppgift att utveckla ett spel idag, för att ta med på en resa 20 år bak i tiden.
Hade man kunnat göra ett mer optimerat spel med dagens programmeringsspråk?

Tack

Egentligen är det ju svårt att veta, för just det du efterlyser, att man gör ett spel och försöker optimera det för t ex Windows 98 är det ju i princip ingen som gör. Däremot händer det ju att det programmeras nya spel för gamla konsoler (där hårdvaran är helt fixerad i tid). Som olika retroprojekt.

Jag tror att man skulle kunna göra bättre saker med gammal hårdvara, men det beror i så fall på andra saker än moderna programmeringsspråk.

Kunskap ackumuleras ju. Om du skulle göra ett NES-spel idag så vet du ju vad man kan göra när man gör det som bäst. Dessutom sprids kunskap och delas betydligt bättre idag, så om det finns ett community där man sitter i olika delar av världen och försöker göra nya bra spel så skulle catch-up-effekten vara stor.

Dessutom kan du testa din kod mycket enklare idag med emulering i din utvecklingsmiljö. Det skulle skapa jättestora tidsvinster idag, att du får direkt feedback och kan testa olika saker.

Apropå NES-spel så har jag en länk med konkreta problem du skulle få om du skulle försöka programmera ett NES-spel i C istället för direkt i assembler.
Citat:
https://shiru.untergrund.net/article...games_in_c.htm
Due to very limited NES resources, such as CPU speed, RAM and ROM size, writting a proper, clean C code isn't very effective. To make it faster and shorter you have to optimize it through doing things that otherwise aren't considered acceptable. They are disable some of C advantages, making the code more low level and less structured, but even with these limitations it remains very high level comparing to assembler.
There are suggestions that will make your code more effective, but certainly less readable:
  • Avoid local variables as much as possible, make them static at least
  • Avoid passing parameters to functions
  • Avoid to use functions that only used once
  • Use __fastcall__ calling convention
  • Arrays of structs are slow, separate arrays are faster
  • Fastest type is unsigned char, use it as much as possible. Don't forget that in CC65 int is 16 bit wide
  • Signed types are slower
  • You can put some variables into zero page using a pragma (see below), it makes them faster
  • Don't forget that you need to declare array of pointers as const type* const if you need to put it into ROM
  • Use preincrements where possible, they are both faster and shorter
  • Avoid to use multiple and division as much as possible, they are very slow. Use bit shifts where possible instead
  • If you need to process an array of objects, it is better to copy data from arrays to separate vars. Use these vars in the code, and then copy new data back to the arrays. This could make code significally shorter and faster, because access to an array item generates more code than access to a variable
  • Declaring global variables as static also helps to find unused global variables, compiler will report about them

Som du ser så måste man undvika nästan allt som man normalt är van vid att göra i ett "modernt" språk, och du är kvar vid att du har en syntax som du är van vid och att vissa saker kan skrivas kortare.
__________________
Senast redigerad av impieteer 2018-01-20 kl. 15:56.
Citera
  • 1
  • 2

Stöd Flashback

Flashback finansieras genom donationer från våra medlemmar och besökare. Det är med hjälp av dig vi kan fortsätta erbjuda en fri samhällsdebatt. Tack för ditt stöd!

Stöd Flashback