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.