P Parkeringsvakten skrev:
Det gör man. har aldrig förstått varför man går runt med bluetooth snäckan i örat HELA tiden. Har sett såna på ICA och som åhörare på barnens fotbollsmatcher mm. Och givetvis ringer det aldrig.
Var tycker du att den ska förvaras medan man väntar på att det ska ringa?

I en ficka blir den ju mosad.
 
  • Gilla
Kirre2 och 1 till
  • Laddar…
K Kirre2 skrev:
På tal om bortförklaringar, det var länge sen jag hörde nån förklara nåt problem med att "det ligger på data"!
"Det är fel på datan" har man ju hört förut. Men inte så mycket längre. Ersatte väl "tryckfelsnisse" ett tag. Vem/vad kan vi skylla på nu? Dålig AI?
 
elpaco elpaco skrev:
Du verkar humorfri. Trots en månads betänketid.
Oavsett denna feud så minns jag reklamen för WAP som löd "Wapratar du om?" och sen nåt om en mobil eller leverantör som stödde Wap.
 
Jonas Persson
useless useless skrev:
Ja, processorhastigheten hade egentligen inget med nätfrekvensen att göra, utan var syncad med VIC-chippet för att antingen funka med PAL eller NTSC. Sen fanns det väl i grund och botten ett beroende till nätfrekvensen, men det var inte så att amerikanska C-64'or gick 20% snabbare.
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."
 
  • Gilla
Fotografen
  • Laddar…
Jonas Persson
S skogaliten skrev:
Var tycker du att den ska förvaras medan man väntar på att det ska ringa?

I en ficka blir den ju mosad.
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.
 
Jonas Persson
Minns orden jokertecken och vagnretur, råtta förekom också. Eller när svenska tidningar talade om nätnav och växel istället för hub/switch.
 
  • Gilla
Fotografen och 1 till
  • Laddar…
P
useless useless skrev:
Ja, processorhastigheten hade egentligen inget med nätfrekvensen att göra, utan var syncad med VIC-chippet för att antingen funka med PAL eller NTSC. Sen fanns det väl i grund och botten ett beroende till nätfrekvensen, men det var inte så att amerikanska C-64'or gick 20% snabbare.
CPUn klockas oftast med en kristallstyrd klocka oberoende av elnätfrekvensen. Jag tror att du syftar på ett videochip med "VIC-chip".
 
Jonas Persson 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."
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.

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
 
useless 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.
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.

Jag körde 1800x, 2700x och 3950x på samma x370 mobo. Nu kör jag x570
 
hsd
Stefan H Stefan H skrev:
"Det är fel på datan" har man ju hört förut. Men inte så mycket längre. Ersatte väl "tryckfelsnisse" ett tag. Vem/vad kan vi skylla på nu? Dålig AI?
Nu skyller alla på covid
 
P
Jonas Persson Jonas Persson skrev:
Minns orden jokertecken och vagnretur, råtta förekom också. Eller när svenska tidningar talade om nätnav och växel istället för hub/switch.
Ja, varför slutade de med det? Det nuvarande språkbruket är en misshandel av ärans och hjältarnas. :-)
 
  • Gilla
  • Haha
Fotografen och 1 till
  • Laddar…
J
AndersMalmgren AndersMalmgren skrev:
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.

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
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... :)

 
  • Gilla
mkristensson och 6 till
  • Laddar…
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]
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 :)

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:
J
AndersMalmgren 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 :)
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...

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...
 
  • Gilla
skaraborgsfakir och 1 till
  • Laddar…
P pmd skrev:
CPUn klockas oftast med en kristallstyrd klocka oberoende av elnätfrekvensen. Jag tror att du syftar på ett videochip med "VIC-chip".
Även CPU-frekvensen skiljde mellan PAL och NTSC.

@ 1.023 MHz (NTSC version)
@ 0.985 MHz (PAL version)
 
  • Gilla
pmd
  • Laddar…
Vi vill skicka notiser för ämnen du bevakar och händelser som berör dig.