[borland C++] 256 kleuren

[kippy]

Hoi, ik ben bezig om op een form iets met 256 kleuren te tekenen. Dit kan heel makkelijk met:

this->Canvas->Pixels[x][y] = (TColor) kleur;

Maar op deze manier kijg je 256x256x256 kleuren. En voor het gene waarvoor ik het wil gebruiken hou ik dan geen snelheid meer over. Nu heb wel een paar ideetje door met bijv loopjes het voor elkaar te krijgen om maar 256 kleuren te kunnen krijgen. maar dan dat kost me ook weer wat snelheid.

nu wilde ik dus weten wat de andere mogelijkheden zijn. je zou een pallete aan kunnen maken maar geen idee hoe dat moet. verder kan ik geen gebruik maken van lib's.

[curry684]

Als jij gewoon op een 256-kleuren TBitmap tekent gaat het OS automagisch palletizen voor je

Alternatief is dat je zelf gaat spelen met TPallette, maar da's echt een schijtwerk

[.oisyn]

kippy schreef op maandag 06 december 2004 @ 14:50:
En voor het gene waarvoor ik het wil gebruiken hou ik dan geen snelheid meer over.

Wat is dat voor een rare insinuatie? Waarom zou een grotere colorspace zoveel langzamer zijn?

[kippy]

curry684 schreef op maandag 06 december 2004 @ 14:53:
Als jij gewoon op een 256-kleuren TBitmap tekent gaat het OS automagisch palletizen voor je

Alternatief is dat je zelf gaat spelen met TPallette, maar da's echt een schijtwerk

Hat gaat jammer genoeg niet om een bitmap, anders was het idd niet zo'n probleem.

[ Voor 24% gewijzigd door kippy op 06-12-2004 15:06 ]

[Spinal]

kippy schreef op maandag 06 december 2004 @ 14:50:...En voor het gene waarvoor ik het wil gebruiken hou ik dan geen snelheid meer over. ...

Ben wel geen C++ programmeur, maar heb wel ervaring met Delphi...
Hou je geen snelheid over vanwege de kleuren of omdat je elke keer 65 duizend pixels moet gaan tekenen? Dat laatste is in Delphi vrij eenvoudig op te lossen door het op een 'virtuele' TImage/TBitmap te tekenen, en die vervolgens met BitBlt te kopiëren naar het 'echte' plaatje. Ik neem aan dat dit in C++ ook mogelijk is.

[kippy]

nee ik wil het real time kunnen, er moeten realtime pixels op het scher worden gezet. de kleur van de volgende pixel is afhankelijk van de vorige. dat kan opzich redelijk snel maar wanneer je een plaatje van 800x600x16bit hebt gaat dit toch wel erg traag. dus wilke ik 256 kleuren gebruiken maar ik krijg et niet "simpel" voor elkaar.

en ben nu aan het kijken naar Tpalette, maar dat vind ik maar een wazig ding......

[pjvandesande]

kippy schreef op maandag 06 december 2004 @ 15:39:
nee ik wil het real time kunnen, er moeten realtime pixels op het scher worden gezet. de kleur van de volgende pixel is afhankelijk van de vorige. dat kan opzich redelijk snel maar wanneer je een plaatje van 800x600x16bit hebt gaat dit toch wel erg traag. dus wilke ik 256 kleuren gebruiken maar ik krijg et niet "simpel" voor elkaar.

en ben nu aan het kijken naar Tpalette, maar dat vind ik maar een wazig ding......

Update hij bij elke pixel? Je kan het beter doen inderdaad door eerst alles te tekenen op een virtuale bitmap en deze weer gewoon te kopieeren.

[Bosmonster]

.oisyn schreef op maandag 06 december 2004 @ 14:56:
[...]


Wat is dat voor een rare insinuatie? Waarom zou een grotere colorspace zoveel langzamer zijn?

Kweet niet, maar een grotere colorspace kost behoorlijk wat meer geheugen?

[.oisyn]

kippy schreef op maandag 06 december 2004 @ 15:39:
nee ik wil het real time kunnen, er moeten realtime pixels op het scher worden gezet. de kleur van de volgende pixel is afhankelijk van de vorige. dat kan opzich redelijk snel maar wanneer je een plaatje van 800x600x16bit hebt gaat dit toch wel erg traag.

Door een 8 bits colorspace te gebruiken wordt het echt niet sneller hoor

Bosmonster schreef op maandag 06 december 2004 @ 16:10:

Kweet niet, maar een grotere colorspace kost behoorlijk wat meer geheugen?

3 of 4 keer zoveel, maar dat maakt het niet trager (hooguit meerdere cache misses, maar dat is een minimaal verschil)

[MSalters]

Volgens mij is een 8-bits colorspace zelfs langzamer als je HW zelf 24 bits is. Moet je elke keer weer een lookup doen.
Ik verdenk de TS eerder van onhandig gebruikt van types. Blijkbaar moet hij voor elke pixel
een cast doen naar TColor - waarom niet direct overal die TColor gbruikt? Daarnaast is een moderne videokaart PCI of AGP, en beide zijn geen 8-bits random-access bussen. Die werken beter als je een hele verzameling bits tegelijk overstuurt, vandaar de goede tip om een BitBlt te gebruiken.

[Creepy]

Daarnaast is het gebruik van de pixels property ook nog eens traag. De pixel property inwisselen voor de scanline property maakt het geheel ook nog eens een stuk sneller.

[curry684]

TColor is technisch een typedef naar een unsigned long oid, dus daar zit geen conversie-overhead. TS is wsch aan het pixelen naar het scherm, en da's idd idioot traag. Lekker naar een offscreen 32-bit bitmap pixelen en in 1 klap op het scherm blitten is een factor 10~20 keer sneller.

[kippy]

het gaat hier nog steeds niet om een bitmap, en ik moet elke pixel "zien" verranderen. Dus mijn vraag is nog steeds is het mogelijk om met een code een pixel op het scherm te zitten met 256 kleuren. ben nog de hele midag opzoek geweest naar code maar het enige wat ik kan vinden is 24 bit code, en dat is veel te traag voor mijn doel.

[Creepy]

Met scanline i.pv. pixels kan je ook prima pixel voor pixel je afbeelding benaderen. En dat gaat een stuk sneller.
En waarom moet je zien dat een pixel verandert? Nu gebeurt dat ook letterlijk en krijg je een refresh van je afbeelding bij elke pixel die je aanpast. Als je het snellert wilt zul je het toch echt anders moeten gaan oplossen zoals hier al meerdere keren is aangegeven

[curry684]

kippy schreef op maandag 06 december 2004 @ 20:29:
het gaat hier nog steeds niet om een bitmap, en ik moet elke pixel "zien" verranderen. Dus mijn vraag is nog steeds is het mogelijk om met een code een pixel op het scherm te zitten met 256 kleuren. ben nog de hele midag opzoek geweest naar code maar het enige wat ik kan vinden is 24 bit code, en dat is veel te traag voor mijn doel.

Je kunt wel blijven herhalen dat het te traag is, maar dat geloven we niet

Laat anders eens wat code zien, een hedendaagse machine hoort zelfs met 800x600 * SetPixel(..) op een 32-bit scherm geen problemen te hebben. Dat krijg je zo ongeveer alleen gedaan als je een complete repaint triggered met iedere pixel, en ja daar kun je dan ook weinig aan doen

[kippy]

curry684 schreef op maandag 06 december 2004 @ 20:54:
[...]

Je kunt wel blijven herhalen dat het te traag is, maar dat geloven we niet

Laat anders eens wat code zien, een hedendaagse machine hoort zelfs met 800x600 * SetPixel(..) op een 32-bit scherm geen problemen te hebben. Dat krijg je zo ongeveer alleen gedaan als je een complete repaint triggered met iedere pixel, en ja daar kun je dan ook weinig aan doen

Das ongeveer wat ik wil, "de volledige repaint" en dan ben je zeker blij met 256 kleurtjes. Het idee is om elke kleur combinatie op 800 x 600 x 256 kleuren te maken. dat is iets van 2.5 ^ 27, dit zal uiteraard een aantal weeken/maanden duren. maar als ik dit in 32 bit doet wordt dit wel een heel erg gestoorde actie. daarom wil ik dus een 256 kleuren palette of iets dergelijk hebben maar ik heb nog steeds geen idee hoe ik dat voor elkaar krijgt. ik kan ook niet dit van te voren in een bitmap stouwen en dan laten zien want dat is uiteindelijk net zo traag.

de enige andere mogelijkheid is DirectX, dat werkt maar dat mag ik weer niet gebruiken (school projectje)

[ Voor 34% gewijzigd door kippy op 06-12-2004 21:02 ]

[Creepy]

kippy schreef op maandag 06 december 2004 @ 20:56:
[...]


Das ongeveer wat ik wil, "de volledige repaint" en dan ben je zeker blij met 256 kleurtjes.

Maar waarom wil je die volledige repaint na elke pixel verandering? Dit maakt het enorm traag.

Het idee is om elke kleur combinatie op 800 x 600 x 256 kleuren te maken. dat is iets van 2.5 ^ 27, dit zal uiteraard een aantal weeken/maanden duren. maar als ik dit in 32 bit doet wordt dit wel een heel erg gestoorde actie. daarom wil ik dus een 256 kleuren palette of iets dergelijk hebben maar ik heb nog steeds geen idee hoe ik dat voor elkaar krijgt. ik kan ook niet dit van te voren in een bitmap stouwen en dan laten zien want dat is uiteindelijk net zo traag.

Als je in een off screen bitmap alles doet en deze met bijv de bitblt() functie naar het scherm kopieert gaat dit stukken sneller dan de methode die je nu gebruikt.

[kippy]

elke mogelijke combinatie op 800 x 600 x (kleurtjes) moet gamaakt worden, dan bedoel ik niet het vlak maar dus voor elk punt op het vlak. wat ik al zij duurt dit ziekelijk lang, maar dat maakt niet heel erg veel uit. alleen wanneer het nu 32bit kleuren zijn is dit niet meer leuk, dan zijn het geen maanden maar jaren en dat is niet helemaal de bedoeling.

als ik het ofscreen met een bitmap zou doen zal het niet veel verschil in snelheid maken. Want of ik nu offcreen pixel voor pixel teken of onscreen, het duurt hoe dan ook lang. maar om het dus binnen de perken te houden van leterlijk weken/maanden wil ik 256 kleuren gebruiken.

[MSalters]

Elke mogelijke combinatie? Jij bent waarschijnlijk niet heel erg goed in wiskunde; dat zijn 256⁴⁸⁰⁰⁰⁰ of 16777216⁴⁸⁰⁰⁰⁰ mogelijkheden. Da's 2^{3 840 000} of 2^{11 520 000}, respectievelijk 10^{128 000} of 10^{384 000}. Stel dat je er 300 per seconde zou kunnen laten zien, da's 10¹⁰ per jaar. Oftewel, met 256 kleuren heb je maar 10000000000000000000000000000[veel]000000000 jaar nodig in plaats van 1000000000000000000[heel veel]0000000000000 jaar

[kippy]

zucht had ik toch maar men wiskunde HBO doorstroom in men pakket genomen.........

naja weer een stuk weizer geworden.