1 749 490 läst ·
15 773 svar
1749k läst
15,8k svar
Saker som vi glömt bort att de har funnits
Var tycker du att den ska förvaras medan man väntar på att det ska ringa?P Parkeringsvakten skrev:
I en ficka blir den ju mosad.
Jonas Persson
Intresserad
· Stockholm
· 2 887 inlägg
Jonas Persson
Intresserad
- Stockholm
- 2 887 inlägg
Googlade lite... Verkar som om NTSC led av att spel utvecklade på PAL inte gick att få till på ett bra sätt utan en massa omkodning. 25/30 bilder per sekund kommer ursprungligen från nätfrekvensen då bilden var tvådelad, interlaced.useless skrev:
"Hardware-wise, the Commodore 64, like most early computers, was synchronized to its graphics output: in the case of the C64, the CPU clock was derived from the timing crystal in the video hardware.
From a game-programming standpoint, the most important timing element is the vertical refresh rate: the 50 Hz (PAL) or 60 Hz (NTSC) rate at which the screen started drawing each frame. A game coded for one frame rate would appear too fast or too slow on the other. Given the limited CPU capabilities of the hardware (you've only got 19,700 or 17,050 CPU cycles per frame), a re-write of the software was often the only way to adapt while still being able to run fast enough."
"The timing of some programs - most notably games - is different due to the different frame rates of NTSC (60 Hz) and PAL (50 Hz). It may also affect the timing of the SID tunes if the SID registers are written during and synchronized to the vertical blanking of the frame."
Jonas Persson
Intresserad
· Stockholm
· 2 887 inlägg
Jonas Persson
Intresserad
- Stockholm
- 2 887 inlägg
Minns fortfarande idioten som stod och pratade för sig själv innan jag insåg att han hade det senaste inom mobiltelefoni, en hörsnäcka med mikrofon (kabelvarianten). Det såg bra skumt ut med en person som stod och pratade rakt ut i tomma luften.S skogaliten skrev:
CPUn klockas oftast med en kristallstyrd klocka oberoende av elnätfrekvensen. Jag tror att du syftar på ett videochip med "VIC-chip".useless skrev:
Renoverare
· Stockholm
· 20 277 inlägg
Varför de inte skalade rörelse som en funktion av tiden måste ju som sagt vara pga begränsning med flyttal på den tiden.Jonas Persson skrev:
Googlade lite... Verkar som om NTSC led av att spel utvecklade på PAL inte gick att få till på ett bra sätt utan en massa omkodning. 25/30 bilder per sekund kommer ursprungligen från nätfrekvensen då bilden var tvådelad, interlaced.
"Hardware-wise, the Commodore 64, like most early computers, was synchronized to its graphics output: in the case of the C64, the CPU clock was derived from the timing crystal in the video hardware.
From a game-programming standpoint, the most important timing element is the vertical refresh rate: the 50 Hz (PAL) or 60 Hz (NTSC) rate at which the screen started drawing each frame. A game coded for one frame rate would appear too fast or too slow on the other. Given the limited CPU capabilities of the hardware (you've only got 19,700 or 17,050 CPU cycles per frame), a re-write of the software was often the only way to adapt while still being able to run fast enough."
"The timing of some programs - most notably games - is different due to the different frame rates of NTSC (60 Hz) and PAL (50 Hz). It may also affect the timing of the SID tunes if the SID registers are written during and synchronized to the vertical blanking of the frame."
Annars är det ju så enkelt som
x += x * 30 * deltaT
DrawPixel((int)x, (int)y)
Vilket kommer flytta x med 30 pixlar per sekund
Renoverare
· Stockholm
· 20 277 inlägg
Kan varit så eller så var det efterkonstruktion hehe . Fyfan vad Intel har stagnerat marknaden i många år genom att hålla oss kvar på 4 kärnor alldeles för länge. En annan grej som AMD gör bra är att man kan köra samma chipset över flera CPU generationer. Intel låser det där med mjukvara för att tjäna pengar på nya chipset.useless skrev:
Vad jag minns (men kan ha helt fel) så började det med separata serier, sen kom man på att DX-proppar med dåliga mattechip kunde säljas som SX istället för att kasseras för att senare glida över till att det var billigare med en tillverkningslina och sälja vissa modeller som SX för att motivera ett högre pris på DX.
Jag körde 1800x, 2700x och 3950x på samma x370 mobo. Nu kör jag x570
hsd
Medlem
· Kalmar län, Östra Götaland
· 7 160 inlägg
hsd
Medlem
- Kalmar län, Östra Götaland
- 7 160 inlägg
Jag programmerade spel för massor av år sen, det fanns då inte tid för sådant finlir. Flyttal? Assembler var ända sättet att få nåt som överhuvudtaget lirade. Och hastigheten? Eftersom man var beroende av var CRT strålen var på skärmen så var man tvungen att anpassa sig till denna. Detta var innan dubbelbuffring var praktiskt möjlig om spelen skulle flyta på. Dvs, håll reda på var strålen är på skärmen och rita inte just där. Om du ritar innan strålen eller efter strålen måste förflyttningen kompenseras för det. Det var på PC jag verkade. Räkna hur många bytes du kan skriva med en 8MHz 286, då är dessutom videominnet rätt segt. Ska du sen ha samplat och mixat ljud i 8kHz så går rätt mycket kraft till det. Det finns ingen tid att styra timingen på det sättet...AndersMalmgren skrev:
Men för er som minns 4.77MHz PCn (jag började programmera på riktigt på 286 / EGA tiden) så finns ett fantastiskt relativt nyskrivet demo som gör saker jag inte trodde var möjliga. Och jag och några till lade ändå en stor del av ungdomen på att räkna klockcykler på intels sämre processorer...
Renoverare
· Stockholm
· 20 277 inlägg
Jag skrev mina första program i Qbasic på en 8086 grafiken i ASM genom att skriva direkt till videominnet. Så jag vet, har varit där jag ocksåJ JohanLun skrev:Jag programmerade spel för massor av år sen, det fanns då inte tid för sådant finlir. Flyttal? Assembler var ända sättet att få nåt som överhuvudtaget lirade. Och hastigheten? Eftersom man var beroende av var CRT strålen var på skärmen så var man tvungen att anpassa sig till denna. Detta var innan dubbelbuffring var praktiskt möjlig om spelen skulle flyta på. Dvs, håll reda på var strålen är på skärmen och rita inte just där. Om du ritar innan strålen eller efter strålen måste förflyttningen kompenseras för det. Det var på PC jag verkade. Räkna hur många bytes du kan skriva med en 8MHz 286, då är dessutom videominnet rätt segt. Ska du sen ha samplat och mixat ljud i 8kHz så går rätt mycket kraft till det. Det finns ingen tid att styra timingen på det sättet...
Men för er som minns 4.77MHz PCn (jag började programmera på riktigt på 286 / EGA tiden) så finns ett fantastiskt relativt nyskrivet demo som gör saker jag inte trodde var möjliga. Och jag och några till lade ändå en stor del av ungdomen på att räkna klockcykler på intels sämre processorer...
[media][media]
Går ju approxa samma sak utan flyttal dock. Men blir mer komplex kod.
Edit: kom ihåg att jag cachade sin(pi) för att inte behöva beräkna det varje frame
Edit: star grejen från första demot gjorde jag i Qbasic kom jag ihåg. Var asstolt. Ska se om jag kan hitta den imorn och kompilera i qb64
Edit: även idag spelar optimering in. Tex fick vi noggrant designa våra structar för ballistics simuleringen. De ligger riktigt tight of fint i cachen på CPU. Kan trycka på flera tusen samtidig utan problem
Redigerat:
Jag har faktiskt en gammal IBM5170 8MHz men med ett lite snabbare grafikkort (VGA isf EGA och ett av de snabbare varianterna från den tiden) samt soundblasterkort som jag vevat igång för nåt år sen och till min glädje fungerade spelet vi portade till PC på denna dator på full frame rate, det är dock nog den absolut sämsta HW det funkar på, 1994 när det släpptes var en 286 redan gammal dock var otroligt många PC spel på den tiden rent utsagt usla på att köra hackigt utan flyt. Jag tror faktiskt vi inte hade en så gammal dator att testa på, men målet då var nog en 12 eller 16MHz 286, så detta var en ren bonus... Jag vågar nog påstå att i princip inget annat spel just då flöt så bra på en äldre HW. Lämnar dock onämnt vad det var för spel i denna tråd då jag ogillar att koppla ihop byggahuslogin med annat googlingsbart på nätet...AndersMalmgren skrev:
Jag skrev mina första program i Qbasic på en 8086 grafiken i ASM genom att skriva direkt till videominnet. Så jag vet, har varit där jag också(fast jag hade nog avancerat till 286 eller tom 386 när jag var så avancerad att jag skrev till videominnet)
Går ju approxa samma sak utan flyttal dock. Men blir mer komplex kod.
Edit: kom ihåg att jag cachade sin(pi) för att inte behöva beräkna det varje frame
Edit: star grejen från första demot gjorde jag i Qbasic kom jag ihåg. Var asstolt. Ska se om jag kan hitta den imorn och kompilera i qb64![]()
Just jag har ju inte glömt bort dessa gamla datorer... Jag har en hög i källaren. Dock tyvärr inte tiden att pyssla om dem...
