[js/css] pellePaint -> comments of verbeteringen?

[Pelle]

Een paar uurtjes geleden kwam ik terug van een fijn tentamen over databases, en aangezien de query's, opslagstructuren en ERDs m'n neus uitkwamen, besloot ik me eens te gaan verdiepen in iets dat wél leuk was.

In /14 loopt momenteel een programmeerwedstrijd, dus ik vond dat ik dat probleem eens op ging lossen. Tijdens het verzinnen van een algoritme had ik opeens een soort van 'eureka', maar dan niet met betrekking tot die wedstrijd, maar over iets wat ik mezelf ooit eens had voorgenomen om te maken: Paint met JS en CSS.

Ja, en als rechtgeaarde W&G-er ga je je daar dan mee bezig houden in plaats van met dat stomme geneuzel van die lui uit /14

* Pelle ging lekker aan de klop, en zie: in 3 uurtjes zat pellePaint v1.0a in elkaar.

Ik heb het getest in IE5.5, Mozilla en Netscape6. In Mozilla & Netscape werkt het, op een paar kleine schoonheidsfoutjes na, maar dat is niet echt veel werk om dat op te lossen.

M'n probleem is eigenlijk een beetje dat het behoorlijk wat CPU-power kost om bijvoorbeeld een area te fillen met de paintbucket. Te snel nog een keer fillen geeft in IE bij mij een stack-overflow (dus vullen als de huidige fill nog niet is uitgevoerd).

In principe sta ik dus open voor alles dat de performance van dit gebeuren kan verbeteren. Ben te lui geweest om een beetje netjes te commenten, maar het is allemaal redelijk duidelijk vind ik zelf. Je hebt een toolbar-object met een aantal properties (color & tool), en met een klik wordt er met behulp van de toolbar-properties gekeken welke methods er op een pixel-object losgelaten moeten worden om het gewenste resultaat te verkrijgen.

Ik wil er nog een lijn-tool in gaan bouwen, en nog wat ongein, en het hele zooitje een beetje opleuken, en de mogelijkheid tot het opgeven van een custom color, enz, maar dat is fase 2. Ik zat in ieder geval met het probleem dat je met de pencil pixel voor pixel in moet kleuren, en dat zuigt. Als iemand bijvoorbeeld een idee heeft over hoe ik dat aan zou kunnen pakken (dus onMouseDown wordt elke pixel waar de muis zich op bevindt, ingekleurd), dan houdt ik me zwaar aanbevolen.

Enniewees, schiet er maar op, ik ben benieuwd naar de reacties (en de performance op een iets minder bruut systeem als het mijn.. kheb hier een Athlon1000 met 512Mb).

[Verwijderd]

Hey Pelle, dit is een geweldig leuk idee

Ik ga er morgen eens naar kijken, die lijn tool moet wel kunnen, en cirkels en rechthoeken enzo ook wel denk ik.

Misschien zelfs anti-aliasing, en zoomen

Er is zeker wel veel mogelijk, maar je geeft het zelf al aan: je moet rekening houden met de performance...

Lijkt me een heel leuk project. Vandaar dat je moet proberen het zo universeel mogelijk te houden, zodat het uitbreidbaar is.

I'm in

[Verwijderd]

Ziet er mooi uit

[Pelle]

Op woensdag 28 november 2001 03:58 schreef Xtentic het volgende:
Ziet er mooi uit

Thanks.
* Pelle vraagt zich wel af waarom er nu nog mensen online zijn. Get a life!

* Pelle moet over 4 uurtjes weer werken

[Verwijderd]

Op woensdag 28 november 2001 04:04 schreef Pelle het volgende:

[..]

Thanks.
* Pelle vraagt zich wel af waarom er nu nog mensen online zijn. Get a life!

* Pelle moet over 4 uurtjes weer werken

haha..

Ik ben vrij, daarom

[Dennis]

Op woensdag 28 november 2001 04:04 schreef Pelle het volgende:
Thanks.
* Pelle vraagt zich wel af waarom er nu nog mensen online zijn. Get a life!

En waarom is meneer zelf nog op ?

[Tim Schuhmacher]

Leuk gedaan.
Simpel 'clear' knopje kan er misschien nog bij.
'undo' en 'redo'

[Verwijderd]

Zeker een kewl project!!!! Als u nog hulp nodig heeft kunt u mij mailen!

[Clay]

vet!

1 ding wat je iig kan doen om het sneller te maken is de object functies Uit de object functie zelf halen, en met object.prototype.functie = functie aan het object te verbinden. Nu worden die functies van pixel namelijk voor elke pixel apart opnieuw aangemaakt, terwijl het met prototyping 1 keer gebeurt. Dat maakt het waarschijnlijk al een stuk sneller.

De stack overflow in de fill krijg ik alleen als ik een veld met de zelfde kleur wil fillen als wat ie al is, en dat is wel logisch, hij springt dan meteen terug naar het vorige veld waar je klikte in het 2e ifje. de check zou ik ook laten kijken of het veld al WEL de nieuwe kleur heeft, dan slaat ie die velden meteen over. js-recursie

Verder zou ik in het pixel object een standaard referentie zetten naar de layer van de pixel, dat je dus niet voor elke style.backgroundColor een getElementById hoeft uit te voeren.

En misschien een optie om zonder border om alle pixels te tekenen ofzo heej maar gaaf man!

[Hangloozz]

vet!

* Pelle krijgt schouderklopje

doet me een beetje aan pakketten als Microangelo denken...
Kan alleen nie saven

Wat ik wel mis (maar wat probably niet kan) is het drag-painten.
Dus een lijn trekken door de muis te bewegen, wat nu resulteert in het selecteren van de inhoud van de cellen.

[Clay]

ik heb het ff geprobeerd, en her werkt een stuk sneller

code:

function pixel() {
   this.kleur    = null;
   this.name     = null;
   this.x     = null;
   this.y     = null;
   this.pixelX   = null
   this.pixelY   = null;

   // toevoegen:
   this.layer    = null;
   this.css = null;
}

pixProto = pixel.prototype;
pixProto.setPos     = setPos;
pixProto.writeDiv   = writeDiv;
// .... enz ....

function writeDiv(x,y) {
   // [oude code]

   // toevoegen:
   this.layer = document.getElementById(this.name);
   this.css   = this.layer.style;
}

en dan verder niet meer getElementById(bla) doen, maar this.css.property = waarde fillen gaat nu op een p500 in een fractie van een seconde.

[M@NIC]

NJ

[Clay]

je kan evt de if() in de flood nog uitbreiden met:

&& this.color != toolBar.color

dan krijg ik die stack overflow alleen nog als ik te ver uit het midden een zeer groot veld wil fillen met een kleur die die niet al is, dus er is toch nog iets mis met die floodfill.

[Pelle]

Op woensdag 28 november 2001 09:16 schreef Tim Schuhmacher het volgende:
Simpel 'clear' knopje kan er misschien nog bij.
'undo' en 'redo'

Dat is best lastig denk ik.. daar heb ik zelf ook al aan zitten denken, maar ik ben er nog niet helemaal uit hoe je dat het beste kunt implementeren. Waarschijnlijk moet je 2 array's bijhouden met alle pixel-informatie; eentje van voor de actie en eentje van erna.

Op woensdag 28 november 2001 09:44 schreef Hangloozz het volgende:
Kan alleen nie saven

Ook daar heb ik al aan gedacht; het zou op zich wel kunnen natuurlijk, maar dan zou ik even een file-format moeten maken, en dat door een php-script laten genereren, die het vervolgens naar je toe mailt. Via een <input type="file"> kun je 'm dan ook weer uploaden, waarna het php-script de benodigde output geeft. Best veel werk, lage prioriteit, maar ook wel cool om te doen.

Wat ik wel mis (maar wat probably niet kan) is het drag-painten.
Dus een lijn trekken door de muis te bewegen, wat nu resulteert in het selecteren van de inhoud van de cellen.

Yep, dat had ik zelf ook al aangegeven; ik heb nog echt geen idee hoe ik dat aan ga pakken. Is wel iets dat ik erin wil hebben namelijk. Iedereen met een bruikbaar idee zal ik opnemen in de credits

Op woensdag 28 november 2001 10:03 schreef Clay het volgende:
ik heb het ff geprobeerd, en her werkt een stuk sneller
[..]
en dan verder niet meer getElementById(bla) doen, maar this.css.property = waarde fillen gaat nu op een p500 in een fractie van een seconde.

* Pelle hoopte al dat Clay dit zou lezen en mij zou voorzien van goeroe-commentaar
Ga ik meteen even uitproberen, thanks!
Ik houd jullie op de hoogte..

[Tim Schuhmacher]

Een geheel eigen bestandsformaat?

je hebt toch niets meer nodig dan een x,y en een kleur van dat vakje? Dat kan dan in een txt file (via php)

[Verwijderd]

Op woensdag 28 november 2001 09:44 schreef Hangloozz het volgende:
Wat ik wel mis (maar wat probably niet kan) is het drag-painten.
Dus een lijn trekken door de muis te bewegen, wat nu resulteert in het selecteren van de inhoud van de cellen.

Kan je dit niet met onMouseOver doen (daar had je zelf waarschijnlijk ook wel aangedacht) Of de positie bijhouden van de muis in pixels, en dmv de coordinaten de blokjes kleuren???

edit--> gevonden

ns

code:

  document.captureEvents(Event.MOUSEMOVE);

ie

code:

window.event.x 
window.event.y

Onmouseover:

Als je op de knop voor het "lijntje trekken" drukt, wordt een variabele(bla) de kleur die je in het kleurmenu gekozen hebt, anders is bla de kleur die het vakje al had(er verandert dus niets).

Bij elke blokje zet je dan onmouseover this.color=bla
sorry dat ik het niet uitgewerkt heb..(aan het werk&shit), dus ik weet niet of het werkt, maar zo zou ik het proberen...

[Pelle]

Op woensdag 28 november 2001 10:43 schreef Tim Schuhmacher het volgende:
Een geheel eigen bestandsformaat?
je hebt toch niets meer nodig dan een x,y en een kleur van dat vakje? Dat kan dan in een txt file (via php)

Ja, dat bedoel ik ook
Maar je wilt in een header misschien nog wel wat dingen opslaan.. afmetingen, naam maker, etc.

Op woensdag 28 november 2001 09:42 schreef Clay het volgende:
1 ding wat je iig kan doen om het sneller te maken is de object functies Uit de object functie zelf halen, en met object.prototype.functie = functie aan het object te verbinden. Nu worden die functies van pixel namelijk voor elke pixel apart opnieuw aangemaakt, terwijl het met prototyping 1 keer gebeurt. Dat maakt het waarschijnlijk al een stuk sneller.

Dat prototyping (kende ik nog niet ) werkt inderdaad stukken sneller, alleen nu krijg je inderdaad stack-overflows bij fillen op sommige coordinaten. Het gekke is dat ik dat in het previewen in Homesite niet heb...

En misschien een optie om zonder border om alle pixels te tekenen ofzo heej maar gaaf man!

Dan moet je de variabele workSpaceSpacing even op 0 zetten Heb ook even de zwarte achtergrond dynamisch gemaakt; je kunt namelijk zelf met workSpaceWidth en workSpaceHeight de afmetingen van je image bepalen, en nu hoef je die layer niet steeds handmatig mee te sizen.

't wordt nog wel eens wat

[waxle]

Een veer in de bips voor Pelle: mad dope.

Chopper + 1!

[Pelle]

Op woensdag 28 november 2001 10:44 schreef jrs het volgende:
Kan je dit niet met onMouseOver doen (daar had je zelf waarschijnlijk ook wel aangedacht) Of de positie bijhouden van de muis in pixels, en dmv de coordinaten de blokjes kleuren???

Yep, zelf ook al aan gedacht; heb alleen helemaal geen ervaring met het capturen van mouse-events. Ben nu ook gewoon aan het werk, dus heb niet echt tijd om dat uit te zoeken. En morgen weer een tentamen PP-04 (Prehistorische Programmeertalen 4: Pascal - oh joy), maar ik hoop dat ik er binnenkort wel tijd voor heb...

Thanks anyhow, zodra ik tijd heb ga ik ermee aan de slag.

[Clay]

Dat prototyping (kende ik nog niet ) werkt inderdaad stukken sneller, alleen nu krijg je inderdaad stack-overflows bij fillen op sommige coordinaten. Het gekke is
dat ik dat in het previewen in Homesite niet heb...

die overflow zat er volgens mij ook al in in het eerste voorbeeld wat je poste. Hij kan iets van driekwart van het tekenvlak elke kant uit fillen vanuit waar je klikt, en als je dat vanuit een hoek doet komt het veld niet vol, alleen redelijk in het midden, en natuurlijk met kleine vlakken, ik snap iig niet waarom
Je zou een andere soort functie kunnen gebruiken die kijkt naar de buur-pixels links boven rechts en onder, en op basis daarvan een recursief filled, maar dan moeten de pixels wel van elkaar weten wat de buren zijn. Ik denk alleen dat je zoiets toch wel nodig hebt als je lijnen wil gaan trekken, en "anti aliased" vormen, smudge tools en weet ik niet wat allemaal

[Helox-in-a-box]

waar blijven de layers en de alpha-channels ?

[drm]

lachen!

Pelle doet net oftie veel tijd heeft in de nachtelijke uren

* drm vindt het cool gedaan

[Pelle]

Op woensdag 28 november 2001 12:03 schreef drm het volgende:
Pelle doet net oftie veel tijd heeft in de nachtelijke uren

Slapen is toch maar tijdverspilling

Heb 'm even geresized van 20x20 naar 16x16 pixels, en nu krijg je geen stack-overflow meer. Denk dat het gewoon aan het toegewezen geheugen ligt ofzo.. aangezien dat probleem zich niet in Homesite voordeed (en dat krijgt blijkbaar meer memory toegewezen dan IE...).

Ik zal eens kijken of NS6 het probleem van die overflow ook heeft.. 't zal me niks verbazen als het daar wel gewoon werkt. Ik heb 'm nu in ieder geval voor even op 16x16 gezet. Minder pixels te neuken, maar dat moet je d'r maar even voor over hebben

[drm]

code:

function calculateDivX(x)

JS Codec lol

[RM-rf]

hij is verschrikkelijk leuk, eventueel het dragpainten kun je door onousedown en trigger te zetten die pas bij document.onmousup weer false wordt

de pixels zelf krijgen dan gewoon een onmouseover functie die de kleur zet als de trigger true is.

wat er dan enkel kan gebeuren is dat je een soort van sleep krijgt die het geheel selecteerd (wat er nu ook is) heb daar niet zo een twee drie een oplossing voor, maar je kunt daarvoor kijken naar dragwindow scriptjes, die roepen vaak eerst een 'lege' functie aan waarvanuit de completere functie wordt uitgevoerd, meen dat dat als een oplossing voor ongewenste drag effecten is.

tja verder zijn de uitbreidingen onbeperkt, een mooier kleurbeheer likt me heel wat waar je ook kleur over kleur kunt leggen en bv met 50% een kleur eroverheen kunt leggen zou heel leuk zijn.

eventueel zou het ook grappig zijn om alle data van je tekening te kunnen submitten en via gdlib er dan een gifje van te bakken.

goh, dit maakt het eigenlijk misschien ook interessant om een illustrator in SVG te gaan maken, in je browser vectoren kunnen tekenen

[Pelle]

Op woensdag 28 november 2001 12:55 schreef RM-rf het volgende:
hij is verschrikkelijk leuk, eventueel het dragpainten kun je door onousedown en trigger te zetten die pas bij document.onmousup weer false wordt

Ik zal het meenemen in m'n verdere code-pogingen. Lukt het niet, dan weet ik je te vinden

eventueel zou het ook grappig zijn om alle data van je tekening te kunnen submitten en via gdlib er dan een gifje van te bakken.

He, dat is natuurlijk helemaal een ranzig goed idee.. dan ga ik een usericon-service starten.. bij mij tekenen, submitten, png bakken, en die kun je dan als usericon gebruiken

Begin het steeds leuker te vinden!

Oh ja: in Netscape6.2 heb ik dat overflow-probleem niet; het ligt dus echt aan het geheugenbeheer van IE

[oh,when?]

Op woensdag 28 november 2001 11:10 schreef Pelle het volgende:
Dat prototyping (kende ik nog niet ) werkt inderdaad stukken sneller, alleen nu krijg je inderdaad stack-overflows bij fillen op sommige coordinaten. Het gekke is dat ik dat in het previewen in Homesite niet heb...

foei!

Ik heb zelf ooit een keer wat geschreven over prototype talen hier, ff zoeken.

FYI, Actionscript is ook een prototype taal

/edit: aha, gevonden

[url="http://gathering.tweakers.net/forum/list_messages/172426"]Op donderdag 28 juni 2001 22:27 schreef oh,when? het volgende:[/url]
En voor de mensen die niet weten waar ik het nu over heb..

Actionscript is een zogenaamde Prototype gebaseerde OOP taal, en gebruikt prototype objects om objecten te defineeren. Je zou het kunnen zien als classes in andere veel striktere talen. Je kunt dus objecten defineren, en zelfs makkelijk extenden, mede omdat Actionscript OOP mogelijkheden best makkelijk zijn itt tot de strikte talen zoals C++ en Java. In deze talen hebben objecten beveiliging ingebouwd. Het is daardoor makkelijker om de class te extenden, maar moeilijk of zelfs onmogelijk de individuele objecten te extenden. Door middel van het Prototype object is het mogelijk bestaande objecten te extenden in Actionscript, omdat je volledig toegang hebt tot het object.

klinkt moeilijk, maar is het niet als je het concept eenmaal begrijpt. Zo is het mogelijk OOP-like te scripten in Actionscript.

Daarnaast is dit nog zeer interesant:

Details of the Object Model - Netscape

Wat evt ook nog leuk zou kunnen zijn in Pellepaint is het volgende:

• Zelf kiezen hoe groot je raster is
• Undo / Redo mogelijkheid ( al eerder genoemd )
• Save Functie ( ook eerder genoemd )
• Load Functie ( dit dus in combinatie met Save functie )
• Gelinkt aan je icon op GoT
• Stem mogelijkheid, wie het beste icon maakt
• In 3D een kubus maken ( uitdaging! )

Mooi gemaakt!

[drm]

Op woensdag 28 november 2001 13:05 schreef Pelle het volgende:
dan ga ik een usericon-service starten.. bij mij tekenen, submitten, png bakken, en die kun je dan als usericon gebruiken

60x60... Dus NS only ivm overflow

[Verwijderd]

/me vindt dat er nog een Ctrl-Z optie in moet...

[Willem]

Je kunt idd (wat RM-rf zegt) kleurbeheer toepassen met meer kleuren. Een leuk idee is de alpha(opacity=x) filter. Dan kom je wel het probleem tegen dat dan de achtergrond wit is, en wat wordt dan de kleur ?

Hmm.. even een gedachtenspinsel Maar, Opzich kun je best deze painter dupliceren om bv. met 2 layers te gaan werken. Dan is dat hele opacity verhaal best toe te passen...

(Alhoewel ik niet weet hoe IE dan eventueel over z'n nek kan gaan..)

[Clay]

Ik denk dat je hier op een wat lage resolutie bezig bent om transparantie echt functioneel te kunnen gebruiken en 60 * 60 (3600 layers!) is wel erg veel om met de hand vol te gaan tekenen

Een gradient lijkt me ook wel leuk, moet ook wel te verwezelijken zijn voor kleuren kan je ook rgb sliders bouwen of gewoon invoervelden. damn d'r is zo veel wat je hiermee kan doen

[oh,when?]

Op woensdag 28 november 2001 13:17 schreef Clay het volgende:
...voor kleuren kan je ook rgb sliders bouwen...

jaa!!! geniaal....

[Willem]

Op woensdag 28 november 2001 13:17 schreef Clay het volgende:
Ik denk dat je hier op een wat lage resolutie bezig bent om transparantie echt functioneel te kunnen gebruiken en 60 * 60 (3600 layers!) is wel erg veel om met de hand vol te gaan tekenen

Nee ik bedoel zo'n zelfde canvas x2.
Boven elkaar. Dan kan het toch gewoon?

(Of zijn die kleine vakjes allemaal layers ?)

Een gradient lijkt me ook wel leuk, moet ook wel te verwezelijken zijn voor kleuren kan je ook rgb sliders bouwen of gewoon invoervelden. damn d'r is zo veel wat je hiermee kan doen

true.

[drm]

Op woensdag 28 november 2001 13:17 schreef Clay het volgende:
Ik denk dat je hier op een wat lage resolutie bezig bent om transparantie echt functioneel te kunnen gebruiken en 60 * 60 (3600 layers!) is wel erg veel om met de hand vol te gaan tekenen

Opzich hoeven alle vakjes niet perse layers te zijn, toch?
Als je er tabelcellen van maakt. slurpt al heel wat minder geheugen.

Maar dan nog zal je voor elke cel een object met status etc. bij moeten houden.... nope 60x60 beetje nutteloos en onhaalbaar.

Een gradient lijkt me ook wel leuk, moet ook wel te verwezelijken zijn voor kleuren kan je ook rgb sliders bouwen of gewoon invoervelden. damn d'r is zo veel wat je hiermee kan doen

gradient is vrij eenvoudig te berekenen.
sliders: leve jouw scrollbars

[Pelle]

Op woensdag 28 november 2001 13:06 schreef oh,when? het volgende:
• Zelf kiezen hoe groot je raster is

Kan nu al, is even 2 vars aanpassen in de source, maar ik ga er wel ff een PHP-file van bouwen waarmee je dat kunt regelen.

• Gelinkt aan je icon op GoT

Dat is ook wel een stoer idee. Een beetje zoals als chem had (tekst submitten die dan in zijn icon kwam), maar dan dat iedere willekeurige onverlaat pixels kan gaan neuken.

• Stem mogelijkheid, wie het beste icon maakt

Hmmja, zou kunnen. Iets voor een later stadium.

• In 3D een kubus maken ( uitdaging! )

Daar had ik ook al aan zitten denken, en is misschien goed te combineren met het aanbrengen van meerdere layers (dan krijg je namelijk ook iets 3-dimensionaals).

Op woensdag 28 november 2001 13:08 schreef drm het volgende:
60x60... Dus NS only ivm overflow

60x60 is misschien wel wat teveel van het goeie, en overflow zorgt ook niet voor crashes in IE; je kunt gewoon verder na die melding namelijk. 't is hooguit vervelend
Daarnaast kun je een icon natuurlijk best maken op 16x16; hier op Got wordt 'ie toch gestretched naar 60x60.

Op woensdag 28 november 2001 13:13 schreef willem169 het volgende:
Hmm.. even een gedachtenspinsel Maar, Opzich kun je best deze painter dupliceren om bv. met 2 layers te gaan werken. Dan is dat hele opacity verhaal best toe te passen...

Yep, opacity is best een leuk ideetje, hoewel ik ook met Clay agree dat het weinig zin heeft met zo weinig pixels.
* Pelle denkt trouwens ook dat willem169's icon roelt

Op woensdag 28 november 2001 13:17 schreef Clay het volgende:
60 * 60 (3600 layers!) is wel erg veel om met de hand vol te gaan tekenen

Inderdaad, en 3600 layers is niet iets dat je wilt denk ik

Een gradient lijkt me ook wel leuk, moet ook wel te verwezelijken zijn voor kleuren kan je ook rgb sliders bouwen of gewoon invoervelden. damn d'r is zo veel wat je hiermee kan doen

Wow, ja daar had ik nog niet aan gedacht. Daar wil ik best een keer een srollbarretje van jou voor gebruiken als dat mag

Op woensdag 28 november 2001 13:29 schreef drm het volgende:
Opzich hoeven alle vakjes niet perse layers te zijn, toch?
Als je er tabelcellen van maakt. slurpt al heel wat minder geheugen.

Ook aan zitten denken. 't wordt dan wat moeilijker om -als je dat zou willen- met posities van pixels te gaan schuiven, maar dat moet je dan maar voor lief nemen. Zal eens kijken of het daadwerkelijk verschil uitmaakt in performance. Kan me goed voorstellen dat de stack in IE gewoon niet hoger kan, en dan maakt het niet uit of je layers of cells gebruikt.

Maar dan nog zal je voor elke cel een object met status etc. bij moeten houden....

Hmm.. of met 3 dimensionale array's gaan werken.. kan ook natuurlijk.. maar dat zou wel een aardig potje herscripten betekenen vrees ik.

Ik ga wel ff een to-do list maken, kunnen jullie de vorderingen live meemaken

[MisterData]

In paint kun je met twee kleuren tegelijk werken, rechtsklikken bijv. wit en links zwart. Dat kun je volgens mij ook erg makkelijk implementeren in JS !

[Pelle]

Op woensdag 28 november 2001 16:18 schreef MisterData het volgende:
In paint kun je met twee kleuren tegelijk werken, rechtsklikken bijv. wit en links zwart. Dat kun je volgens mij ook erg makkelijk implementeren in JS !

Yep, daar attendeerde Eamelink me ook al op via ICQ. Heb 'm meteen opgenomen in de todo-list (die nu behoorlijk groot is ): * klik *

Beetje jammer dat ik 't zo druk heb, maar 't heeft allemaal geen haast gelukkig. Mocht iemand al een idee hebben over hoe een van die todo-dingen te implementeren is, laat het me maar even weten en je verdient een plekkie bij de credits

[drm]

Op woensdag 28 november 2001 16:35 schreef Pelle het volgende:

[..]

Yep, daar attendeerde Eamelink me ook al op via ICQ. Heb 'm meteen opgenomen in de todo-list (die nu behoorlijk groot is ): * klik *

Beetje jammer dat ik 't zo druk heb, maar 't heeft allemaal geen haast gelukkig. Mocht iemand al een idee hebben over hoe een van die todo-dingen te implementeren is, laat het me maar even weten en je verdient een plekkie bij de credits

ik wil wel een fileinterface bouwen in php.

[oh,when?]

Op woensdag 28 november 2001 17:00 schreef drm het volgende:

[..]

ik wil wel een fileinterface bouwen in php.

• execCommand save optie..

wil ik wel maken

[Verwijderd]

die puzzel opdracht is best pittig....mot er nie aan denken.

[Verwijderd]

lachuh!
icon editor voor got zal er wel niet inzitten op 60x60..

heb ff testje gedaan in flash....die heeft het best zwaar in een 60x60 grid

B.

[Pelle]

Op woensdag 28 november 2001 19:29 schreef B-Top het volgende:
heb ff testje gedaan in flash....die heeft het best zwaar in een 60x60 grid

Heb voor de gein ook even een 60x60 uitgeprobeerd in IE en NS6, maar dat is inderdaad geen doen. Het blijkt dat NS6 geen melding geeft van stack-overflow, maar gewoon stopt met het uitvoeren van het script.
Leuk om te weten

[Verwijderd]

dan zou ik voor 30x30 gaan...en daarna upscalen in het array...

[cjs]

Gebruik deze floodFill functie als je van de stack-overflow af wilt.
Hij gebruikt geen recursie, maar is desondanks bijna even snel.

code:

      function floodFill(oldColor) {
        if (this.color == oldColor && this.color != toolBar.color) {
            var workSquare, tempBottom = 0, tempTop = 1, tempArray = new Array(), tempObj;
            tempArray[tempBottom] = this;
            while(tempBottom != tempTop){
              workSquare = tempArray[tempBottom];
              if ((workSquare.x + 1) <= workSpaceWidth) {
                tempObj = workSpace[workSquare.y][workSquare.x + 1];
                if (tempObj.color == oldColor){
                    tempArray[tempTop] = tempObj;
                    tempObj.setColor();
                    tempTop++;
                }
              }
              if ((workSquare.x - 1) >= 1) {
                tempObj = workSpace[workSquare.y][workSquare.x - 1];
                if (tempObj.color == oldColor){
                    tempArray[tempTop] = tempObj;
                    tempObj.setColor();
                    tempTop++;
                }
              }
              if ((workSquare.y + 1) <= workSpaceHeight) {
                tempObj = workSpace[workSquare.y + 1][workSquare.x];
                if (tempObj.color == oldColor){
                    tempArray[tempTop] = tempObj;
                    tempObj.setColor();
                    tempTop++;
                }
              }
              if ((workSquare.y - 1) >= 1) {
                tempObj = workSpace[workSquare.y - 1][workSquare.x];
                if (tempObj.color == oldColor){
                    tempArray[tempTop] = tempObj;
                    tempObj.setColor();
                    tempTop++;
                }
              }
              tempBottom++;
            }
        }
      }

[Verwijderd]

Ik heb het zo even bekeken en vind het er erg leuk uitzien. Het nut begrijp ik er niet van, maar denk dan ook niet dat dat de bedoeling van het project is.

Wat mij leuk lijkt om te zien is het roteren van het plaatje (bijv. per 90 graden oid). Lijkt me wel een uitdaging al moet het te doen zijn.

Verder heel leuk gedaan, mijn complimenten!

[Verwijderd]

een selectie kader tool is ook wel welkom

[Thijsmans]

Ik mis het lijntjes trekken! een must!

[Verwijderd]

M'n complimenten Pelle...

[Clay]

Ik heb nog even wat gespeeld het lijkt mij echt dat een pixel weten moet welke pixels zich boven, onder, links en rechts van zichzelf bevinden, en als je dat doet krijg je het volgende:

code:

// aan pixel object 1 property toevoegen, neighbours:
function pixel() {
   [...]

   this.nbs = [];
}


// de layer bouw for loop ietsie aanpassen zodat pixels 
//weten welke pixels zich er direct naast bevinden:

var ofs = [0,-1,0,1,0]; //hulpje

function processPixels(type) {
   for (var i = 1; i <= workSpaceHeight; i++) {
    if(type == 'create') workSpace[i] = new Array(workSpaceWidth);
    for (var j = 1; j <= workSpaceWidth; j++) {
       if(type == 'create') {
        workSpace[i][j] = new pixel();
        workSpace[i][j].writeDiv(j,i);
        workSpace[i][j].setPos(calculateDivX(j),calculateDivY(i));
       } 

       // nieuw stukje:
       if(type == 'relate') {
        for(var k=0; k<4; k++) {
           nx = j+ofs[k+1]; ny = i+ofs[k] 
           if(nx > 0 && ny > 0 && workSpace[ny])
            workSpace[i][j].nbs[k] = workSpace[ny][nx]; 
        }   
       }
    }
   }
}

processPixels('create');
processPixels('relate');


// en dan ziet de floodfill er ineens zo uit:

function floodFill(oldColor) {
   
   this.setColor();
   
   for(var i=0; i<4; i++) {
    var pix = this.nbs[i];
    if(pix && pix.color == oldColor && pix.color != toolBar.color)
       pix.floodFill(oldColor);
   }       
}

da's denk ik ook makkelijker met nog te maken effecten maken, zoals circels, lijnen, antialiasing egzmd
1 klein probleempje alleen, de stack overflow krijg ik hiermee nog steeds met grote vlakken

[Pelle]

Wow, wat een reacties.. dat had ik niet verwacht
Ben nu nog even bezig met wat andere zaken, maar ik zal straks eens even eea gaan implementeren.

oh,when? is bezig met het execCommand-verhaal, en Clay heeft zich dus ook weer even druk gemaakt
Ik ook nog even kijken naar cjs' verhaal; wellicht is het niet nodig als we gewoon de 16x16 workspace aanhouden, aangezien het anders toch veel te veel layers gaan worden en de browser echt moeite krijgt met het processen van zoveel layers.

Nogmaals: bedankt voor alle hulp & reacties

[MAZZA]

We demand icons!!

Zonder gekheid, knap staaltje klussen hier palle

[Verwijderd]

Ik ben nog niet echt aan scripten toegekomen, maar ik zit, net als iedereen hier, vol met ideeën.

Je kunt voor een fill niet alleen een egale kleur gebruiken, maar ook een gradient.

Ik denk dat een 'werklaag' handig zou zijn, dan kun je inderdaad met selecties werken. Die werklaag zou dan een 2-dimensionale array, gevuld met true/false zijn. (Geselecteerd of niet)

De mogelijkheden zijn eindeloos

[Yellow|A]

* Yellow|A heeft net pipi langkous lopen tekenen in pellepaint

[oh,when?]

* oh,when? is ook ff bezig geweest.

Hoewel ik eigenlijk me bezig zou houden met het saven, heb ik eerst

• clear image

aangepakt. De huidige oplossing is een rare, omdat setColor een method is van toolbar. Deze zet de color aan de hand van toolbar.color. Dus ik zet nu eerst een tempcolor die de huidige waarde bevat van toolbar.color, zet hem dan naar color, en als ik alle velden heb doorlopen, zet hem weer naar tempcolor.

Nu de code ( Javascript in PHP tags want kleurtjes roelen )

PHP:

<?
function clearCanvas(color) {
            this.toolBar = toolBar;
            tempColor = toolBar.color;
            toolBar.color = color;
            for (var i = 1; i <= workSpaceHeight; i++) {
                for (var j = 1; j <= workSpaceWidth; j++) {
                    workSpace[i][j].setColor();
                }
            }
            toolBar.color = tempColor;
        }
?>

en de html code:

code:

<tr>
    <td class="tool" onClick="clearCanvas('#ffffff')" colspan="2">clear</td>
</tr>

HTH

[Pelle]

Op woensdag 28 november 2001 22:31 schreef oh,when? het volgende:
De huidige oplossing is een rare, omdat setColor een method is van toolbar.

Nee, dat is niet helemaal waar. Er zijn 2 setColor()'s aanwezig: eentje als method op het prototype pixel, en eentje op toolBar. Die eerste is de goeie natuurlijk, en ik heb het nu zo gedaan:

PHP:

<?
/* dit is dus de method op het prototype pixel, en niet op toolBar ! */
function setColor(color) {
    /* parameter 'color' toegevoegd, en de kleur wordt nu bepaald
       aan de hand van 'color'. Bestaat hij, dan krijgt hij die
       waarde, bestaat hij niet, dan de waarde van toolBar */
    this.color = (color) ? color : toolBar.color;
    this.css.backgroundColor = this.color;
}


/* dit is een 'gewone' functie die per object een bepaalde
   kleur set, die dus niet gelijk hoeft te zijn aan de
   kleur van de toolbar. */
function clearCanvas(color) {
    for (var i = 1; i <= workSpaceHeight; i++) {
        for (var j = 1; j <= workSpaceWidth; j++) {
            workSpace[i][j].setColor(color);
        }
    }
}
?>

Heb ook even een extern stylesheet toegevoegd, om het allemaal een beetje overzichtelijk te houden.

[2]

*klap klap klap* mensenkinderen wat een stoerheden.

Inderdaad een clear knopje zou leuk zijn. Punt nu is bijvoobeeld, als ik een wit vakje bijv. rood kleur, en vervolgens weer wit, en dan met het emmertje aan de slag ga hij het witte vakje wit laat.

[oh,when?]

Op woensdag 28 november 2001 23:03 schreef Pelle het volgende:

[..]

Nee, dat is niet helemaal waar. Er zijn 2 setColor()'s aanwezig: eentje als method op het prototype pixel, en eentje op toolBar. Die eerste is de goeie natuurlijk, en ik heb het nu zo gedaan:

verrek

hahah die had ik niet eens opgemerkt..

[Pelle]

Op woensdag 28 november 2001 23:06 schreef 2 het volgende:
Inderdaad een clear knopje zou leuk zijn. Punt nu is bijvoobeeld, als ik een wit vakje bijv. rood kleur, en vervolgens weer wit, en dan met het emmertje aan de slag ga hij het witte vakje wit laat.

Stom, dat had ik nog niet eens gezien. 'k heb het opgelost nu; this.color had een beginwaarde van null, en dat schiet niet echt op . Zal zo weer even uploaden.

[Verwijderd]

holy smoly. dit gaat boven mn pet, maar 1 ding is zeker : pelle pakt de beker!


errug leuk

[XangadiX]

cool... maar als ik mijn muisknop inhoud wil ik de lijn doortrekken en niet gaan selecteren

[Pelle]

Op donderdag 29 november 2001 00:05 schreef XangadiX het volgende:
cool... maar als ik mijn muisknop inhoud wil ik de lijn doortrekken en niet gaan selecteren

Yep, dat wil ik ook, en dat staat op de todo-list
Nieuwe versie weer online; ff wat relaxtere layout neergezet en een oplossing voor 2's bugreport erin verwerkt.

[2]

*tap tap*

braaf

[oh,when?]

* oh,when? is bezig met undo/redo functie.

ok..nog ff mijn update:

PHP:

<?
function getColor(name) {
            return document.getElementById(name).style.backgroundColor;
        }
?>

in init ( writediv)

PHP:

<?
this.css.backgroundColor = this.color;
?>

(thnx Pelle )

en dan is de volgende informatie per pixel op te vragen zodra erop wordt geclicked:


• layerID van pixel
• nieuwe kleur van de pixel
• oude kleur van de pixel


Dit stop ik in een 3-dimensionale array genaamd undo:

undo[PixelName][pixelNewColor][pixelOldColor];

Nu is het mogelijk door deze array te lopen, zelfs een max in te stellen ( max level of undo ) en aan de hand van deze informatie een undo / redo te simuleren.

Als er iemand nog tips heeft, graag.

[Verwijderd]

Het is zelfs mogelijk met layers te werken:

Een aantal lagen over elkaar, bij een hogere laag wordt telkens de procentuele opacity maal het verschil tussen de kleuren (RGB) opgeteld.

Maar dat is voor latere zorg Ook gradients moeten kunnen, etc, etc...

[Pelle]

* Pelle is druk aan het ICQ'en geweest met oh,when? die de undo-meuk wel wou proberen

Zelf heb ik in de tussentijd nog een realsize-preview ingebouwd (die helaas wel ten koste gaat van de performance ):

Functie'tje toegevoegd:

PHP:

<?
        function setPreviewColor(parentName,parentColor) {
            previewName = "pre" + parentName;
            document.getElementById(previewName).style.backgroundColor = parentColor;
        }
?>

Wordt aangeroepen in de setColor()-method van een pixel:

PHP:

<?
        function setColor(color) {
            this.color = (color) ? color : toolBar.color;
            this.css.backgroundColor = this.color;
            setPreviewColor(this.name, this.color);
        }
        
?>

Hier zit overigens ook al een color-parameter verwerkt; deze wordt bijvoorbeeld gebruikt door clearCanvas(). Eerst gebruikte setColor() namelijk toolBar.color, maar wil je je image clearen dan moet hij wit gebruiken inplaats van toolBar.color. Vandaar da'k dat er ook in geimplementeerd heb. Als laatste komt dit stukje code in de html:

PHP:

<?
<div id="preview">
    <b>preview</b><br>
    <table border="0" cellspacing="0" cellpadding="0" align="center">
        <tr>
        <script language="javascript" type="text/javascript">
        <!--
            previewSize = 1;
            for (var i = 1; i <= workSpaceHeight; i++) {
                document.write("<tr>");
                for (var j = 1; j <= workSpaceWidth; j++) {
                    prevName = "pre" + (((j-1) * workSpaceWidth) + i);
                    document.write('<td><div id="' + prevName + '" style="background-color: 
                        #ffffff;"><img src="spacer.gif" width="' + previewSize + '" height="' + 
                        previewSize + '" border="0" alt=""></div></td>');
                }
                document.write("</tr>");
            }

        // -->
        </script>
        </tr>
    </table>
</div>
?>

De variabele previewSize bepaalt de pixelgrootte van de pixels in de preview. Staat nu op 1, zoals het hoort, maar als dit ding later gestretched gaat worden naar 60x60, dan kan je 'm beter op 4 zetten.

(verder: alles tussen php-tags, maar dat is dus mooi ivm de kleurtjes )

[Pelle]

Op woensdag 28 november 2001 23:27 schreef JayAnzee het volgende:
holy smoly. dit gaat boven mn pet, maar 1 ding is zeker : pelle pakt de beker!

Nog niet te vroeg juichen hoor, er moet echt nog superveel gebeuren wil het een beetje leuk werken. Denk trouwens ook dat het op een gegeven moment zo'n onoverzichtelijke bende wordt, die code, dat ik 'm helemaal opnieuw ga schrijven, maar dan in 3 uur tijd from scratch

Nu kan ik geen JS meer zien; ff wat unrealen en dan slapie doen.. vannacht niet zo bijster veel geslapen

[Clay]

whoa! preview is roelio!

Maar idd erg zwaar, kan je dat niet beter achter een knopje zetten ala "klik hier voor een preview"? met evt een optie voor realtime preview dat je iig de keuze hebt?

ik ga vandaag eens kijken of ik iets met anti-aliasing kan doen voor tekenen met grotere brushes, fillen met feather enzo. Ik denk dat je dan wel de kleuren in een pixel moet opslaan in 3 losse rbg waardes van 0 - 255, die bij het tekeken naar het scherm pas omgezet worden in een #xxxxxx code om dus makkelijker effecten te kunnen doorrekeken.
op www.xs4all.nl/~elout/ staan hele vette applets die ook per-pixel werken, op ~elout/tuto/ staan als het goed is wat tutorials en voorbeeldcode, die kleurtrucjes schijn je met bitwise shiften makkelijk te kunnen doen, maar dat snap ik nog ff niet

[edit]

wat je nog wel kan doen is van een preview pixel een propertie van het pixel object maken, en ook bij het opbouwen een referentie naar die layer leggen net als bij de layer van de pixel zelf zodat je niet voor elke click een getElementById hoeft uit te voeren, daar wordt de realtime preview iets van 2 a 3 keer zo snel door.

[drm]

Op donderdag 29 november 2001 01:16 vroeg oh,when? of er iemand tips had over undo en redo functies

Ik heb wel een tip.

Als je een undo/redo functie heb, kun je het misschien beter op een andere manier doen.

Initializeer 2 Stacks. 1 History stack en 1 Future stack.

Voor elke "actie" die gedaan wordt, een object aanmaken die 2 methoden heeft, (namelijk: "do" en "undo"), en voer de actie uit door

code:

performed = new Action ( functionName, parameters );
performed.do ();

Plaats vervolgens het object op de History stack. En zo voor alles wat er gedaan wordt.

code:

performed = new Action ( functionName, parameters );
performed.do ();
History.push ( performed );

Stel, er wordt "undo" geclickt, dan pop je het laatste Action element vanaf de stack, undo() je hem, en zet je hem op de Future Stack. Als er dan op redo geclickt wordt, pop je het laatste element van de Future
stack, do() je hem, en zet je hem weer op de History stack.

code:

function undo ()
{
   tmp = History.pop ();
   tmp.undo ();
   Future.push ( tmp );
}

function redo ()
{
   tmp = Future.pop ();
   tmp.do ();
   History.push ( tmp );
}

Dan kan je je overwegen om de Future stack leeg te gooien op het moment dat er na een undo weer een nieuwe action aangemaakt wordt, maar je kunt die future stack ook bewaren. (checkboxje?)

code:

if ( document.getElementById ( 'deleteRedoListOnAction' ).checked == "checked" )
   while ( Future.pop () ) 
    ;

Op die manier kun je een volgende situatie krijgen:
• Teken pixel daar History.push ( new Action ( blabla ) )
• Teken lijn daar History.push ( new Action ( blabla ) )
• Doe Floodfill daar History.push ( new Action ( blabla ) )
• Undo (ik wou toch een andere afbakening....) tmp = History.pop (); tmp.undo(); Future.push ( tmp );
• Teken lijn daar en daar (History.push ( new Action (blabla) );
• Redo tmp = Future.pop (); tmp.do(); History.push ( tmp );

Dan moet je alleen een complete abstractie gaan verzinnen voor elke actie en haar parameters, zodat je die in een object kunt stoppen en anytime anywhere can "do"-en en "undo"-en.

Om maar even in de OOP sfeer te blijven:
Je kunt ipv. 2 stacks van allemaal "Actions" ook 2 stacks van allemaal "derived Actions" maken...

* drm gaat even zoeken hoe dat ook al weer zat in JavaScript met parent classes en inheritance ...
[edit: kan het niet meer vinden. Is ook niet echt boeiend...]

Ondertussen kan ik je wel een implementatie geven van een Stack, scheelt je weer vijf minuten typwerk

PHP:

<?
// php voor de heeeeeeerlijke kleurtjes
function Stack ()
{
   this.data = new Array ();
   this.size = 0;  // points to the next empty entry in data array.
   
   this.push = push;
   this.pop  = pop;
   
   function push ( item )
   { 
      return this.data [ this.size ++ ] = item;
   }
   
   function pop ()
   {
      if ( this.size > 0 )
         return this.data [ --this.size ];
      else
         return null;
   }

   function peek ()
   {
      return this.data [ this.size -1 ];
   }
}
?>

_{edit: even wat netter en peek() functie toegevoegd}

[Woudloper]

* drm gaat even zoeken hoe dat ook al weer zat in JavaScript met parent classes en inheritance ...
[edit: kan het niet meer vinden. Is ook niet echt boeiend...]

Drm, is dit iets wat je zoekt (zocht, want her is niet meer zo interesant )

Object-Oriented Programming with JavaScript, Part I: Inheritance

Object-Oriented Programming with JavaScript, Part II: Methods

[drm]

Op donderdag 29 november 2001 11:54 schreef rwoudsma het volgende:

[..]

drm, is dit iets wat je zoekt (zocht, want her is niet meer zo interesant )

Object-Oriented Programming with JavaScript, Part I: Inheritance

Object-Oriented Programming with JavaScript, Part II: Methods

ja precies, Ik kon ze al niet meer vinden... niet bar hard gezocht, tho... thanx anyway

[Clay]

Volgens mij kan je vanuit een histroy niet zomaar acties van de toolbar aanroepen zoals de floodfill. Als ik bij een vorm met een zwart randje het randje dezelfde kleur geef als de inhoud kan ik dat randje niet terugfloodfillen, dan zou het hele vlak eraan gaan.

In een history zou ik gewoon een lijstje met pixels bijhouden die door de actie die de gebruiker uitvoerde veranderd zijn, en undo verandert die pixels gewoon terug, zonder (veel) toolbar dingen te begruiken.
De history kan dan ook gewoon 1 array met history objecten zijn, waarin je als gebruiker normaal gesproken op de laatste positie staat. Bij een undo ga je 1 positie terug, waardoor je meteen de redo klaar hebt liggen.

Dit gaat nog eens op photoshop lijken

[oh,when?]

Op donderdag 29 november 2001 13:45 schreef Clay het volgende:
In een history zou ik gewoon een lijstje met pixels bijhouden die door de actie die de gebruiker uitvoerde veranderd zijn, en undo verandert die pixels gewoon terug, zonder (veel) toolbar dingen te begruiken.
De history kan dan ook gewoon 1 array met history objecten zijn, waarin je als gebruiker normaal gesproken op de laatste positie staat. Bij een undo ga je 1 positie terug, waardoor je meteen de redo klaar hebt liggen.

Ik had ook zoiets in me hoofd, echter iets uitgebreider. Want als je bijv een cirkel maakt, worden er veel meer pixels bijgewerkt dan dat er maar 1 pixel wordt veranderd.

Dus eigenlijk wilde ik 2 arrays gaan bijhouden:

undo [action][pixels_veranderd]

waarbij pixels_veranderd weer een array is die het aantal pixels bevat die veranderd zijn met de action.

array-undo [action],[array-pixels[pixelname],[pixeloldColor],[pixelnewColor]]

Zo iets dus.


Dus eigenlijk toch een soort stack

[Clay]

dat bedoel ik ook 1 pixel per histroy entry is wat aan de weinige kant. Dus inderdaad pixels per action, maar de action op zich hoef je dan niet op te slaan, een lijst met pixels met hun oude kleur(en) lijkt me genoeg.

[oh,when?]

Op donderdag 29 november 2001 13:56 schreef Clay het volgende:
dat bedoel ik ook 1 pixel per histroy entry is wat aan de weinige kant. Dus inderdaad pixels per action, maar de action op zich hoef je dan niet op te slaan, een lijst met pixels met hun oude kleur(en) lijkt me genoeg.

In principe hoef je action niet op te slaan, echter het is wel handig want die kun je later gebruiken in je GUI ( Undo "Clear Pixel" )

[drm]

Clay:
dat bedoel ik ook 1 pixel per histroy entry is wat aan de weinige kant. Dus inderdaad pixels per action, maar de action op zich hoef je dan niet op te slaan, een lijst met pixels met hun oude kleur(en) lijkt me genoeg.

What's the difference? Als je een action object hebt wat juist die informatie bevat is het toch veel eenvoudiger af te handelen dan allerlei geneste arrays

En als je het bij 1 array houdt, dan kan je dus per pixel maar 1x undo doen...

[edit]
Wat betreft die "per action maar 1 pixel" opmerking:
je kunt elke actie terugredeneren tot een reeks van setColors op een reeks pixels. Dus 1 action bevat dan zo'n reeks, en is niet onderdeel van zo'n reeks. if you get what i mean

[Pelle]

* Pelle zat zelf ook aan een soort van stack te denken voor het maken van een undo/redo

Het leek mij handig om alle pixelinformatie op te slaan in een 2-dimensionale array. Aan het begin ziet die array er dan zo uit (in een grid van 3 bij 3):

code:

#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff

Na het performen van een actie sla je ze weer op; ik wil bijvoorbeeld de pixel linksboven zwart maken. De array komt er dan zo uit te zien:

code:

#000000 #ffffff #ffffff
#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff

En het leuke is dat je die in een 3-dimensionale array achter elkaar kunt plakken. Bij het undo-en haal je de voorste plak uit de drie-dimensionale array weer terug. Is denk ik vrijwel hetzelfde als wat drm bedoelt; ik zal vanavond eens kijken of ik die stack kan implementeren.

Zal de aanbevelingen van Clay ook even meenemen; en ik kreeg ook wat gemaild van rwoudsma, maar een HTML-file attachen resulteert in Eudora in het eruit slopen van alle JS (aangezien hij hem inline weergeeft, en niet als attachment) dus daar heb ik niet zoveel aan. Zou je die file nog een keer kunnen zippen en mailen, of beter nog: de functies die je hebt toegevoegd hier even kunnen plaatsen?

[drm]

Op donderdag 29 november 2001 14:55 schreef Pelle het volgende:
* Pelle zat zelf ook aan een soort van stack te denken voor het maken van een undo/redo

(...)

Is denk ik vrijwel hetzelfde als wat drm bedoelt

Neu, dat geloof ik niet. Ik denk namelijk dat als je het op die manier doet je bij een reeks van veel acties veel te veel dubbel opgeslagen data hebt:

Stel situatie 0 is een 2d array (ff alleen 0 en 1 is wat overzichtelijker:

code:

0 0 0
0 0 0
0 0 0

nou doen we een actie drawpixel (0,0);

dan is situatie 1:

code:

1 0 0
0 0 0
0 0 0

maar voor de pixels (0,1) t/m (2,2) heb je dezelfde status als in de vorige situatie. Dus heb je voor breedte x hoogte -1= 8 pixels dubbele data opgeslagen. Hoe groter het raster, en hoe meer history entries, hoe zwaarder de load...

dwz. als ik * Pelle 's idee goed begrijp...

* drm zit even te denken hoe hij het beste uit kan leggen wat hij bedoelt....

Ik ga het wel even uitwerken...

[oh,when?]

Op donderdag 29 november 2001 14:55 schreef Pelle het volgende:

Het leek mij handig om alle pixelinformatie op te slaan in een 2-dimensionale array. Aan het begin ziet die array er dan zo uit (in een grid van 3 bij 3):

code:

#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff

Na het performen van een actie sla je ze weer op; ik wil bijvoorbeeld de pixel linksboven zwart maken. De array komt er dan zo uit te zien:

code:

#000000 #ffffff #ffffff
#ffffff #ffffff #ffffff
#ffffff #ffffff #ffffff

En het leuke is dat je die in een 3-dimensionale array achter elkaar kunt plakken. Bij het undo-en haal je de voorste plak uit de drie-dimensionale array weer terug. Is denk ik vrijwel hetzelfde als wat drm bedoelt; ik zal vanavond eens kijken of ik die stack kan implementeren.

Het 'probleem' is dat je dan voor elke verandering een array van 16 x 16 = 256 objecten moet vullen. Is dat niet onnodig groot? Wat ik je gisterennacht al vertelde...

[oh,when?]

Op donderdag 29 november 2001 15:12 schreef drm een theorie:
...

Wat misschien ook wel een uitdaging is om per verandering alleen de verandere pixels op te slaan. Dan krijg je een soort probleem zoals de eerste opdracht van de /14 programmeerwedstrijd, dat je een algoritme moet verzinnen om deze te ontleden.

Ook wel interesant.

[drm]

Op donderdag 29 november 2001 15:34 schreef oh,when? het volgende:

[..]

Wat misschien ook wel een uitdaging is om per verandering alleen de verandere pixels op te slaan. Dan krijg je een soort probleem zoals de eerste opdracht van de /14 programmeerwedstrijd, dat je een algoritme moet verzinnen om deze te ontleden.

Ook wel interesant.

* drm heeft iets uitgewerkt. online in a moment...

_edit:

drm's history tracker is done
history test

Heb niet alle errors etc. afgevangen, maar het wijst zichzelf wel, denk ik.

Had ook niet zo veel zin om heel erg uitgebreid te gaan becomentarieren, dus als je vragen hebt moet je ze maar ff hier stellen of ff via mail of icq #61628736

Ik hoop dat nu eindelijk mijn principe een beetje duidelijk is

[Clay]

Op donderdag 29 november 2001 14:13 schreef drm het volgende:

[..]

What's the difference? Als je een action object hebt wat juist die informatie bevat is het toch veel eenvoudiger af te handelen dan allerlei geneste arrays

En als je het bij 1 array houdt, dan kan je dus per pixel maar 1x undo doen...

[edit]
Wat betreft die "per action maar 1 pixel" opmerking:
je kunt elke actie terugredeneren tot een reeks van setColors op een reeks pixels. Dus 1 action bevat dan zo'n reeks, en is niet onderdeel van zo'n reeks. if you get what i mean

volgens mij snap ik jou niet, en jij mij niet

ik wil een history maken waarbij bepaalde acties een history stadium afsluiten en een nieuwe creeren, de pixels die er binnen zo'n stadium veranderd zijn komen allemaal in een lijst, en zo kan je per undo of redo zoveel pixels tegelijk wijzigen als je wil.

code:

// schematisch:
history {
  stadium[0] = [
    [pixel, kleur],
    [pixel, kleur],
    [pixel, kleur],
  ]

  stadium[1] = [
    [pixel, kleur],
    [pixel, kleur],
    [pixel, kleur],
  ]
}

en het history object doet niets anders dan bladeren in die stadia. Bij het coden komt het er op neer wanneer je wat aan een history stadium toevoegd, en wanneer je een stadium sluit en opent.
Ik heb dit al bijna werkend trouwens oneindige undo's en redo's, met groepen pixels dus.

[drm]

Clay vertelde wat hij bedoelde

zie ff ^^ voor mijn idee (2 posts terug)

het verschil is dat jij data bijhoudt, en ik acties... Ik weet eigenlijk niet wat dat in performance of onderhoudbaarheid etc uitmaakt...

Maar 1 groot voordeel van mijn idee, is dat je het op alles toe kan passen, dus niet alleen grafische functies, maar alle functies die je maar kan verzinnen met zoveel argumenten als je maar wilt

* drm is wel benieuwd wat de js-guru's hier van vinden...

[oh,when?]

Op donderdag 29 november 2001 16:49 schreef drm het volgende:
het verschil is dat jij data bijhoudt, en ik acties... Ik weet eigenlijk niet wat dat in performance of onderhoudbaarheid etc uitmaakt...

* drm is wel benieuwd wat de js-guru's hier van vinden...

Wat ik me dan afvraag is wat je je dan voorstelt bij een actie? Een actie bestaat uit een handeling die data-verandering tot gevolg heeft. Hoe wil je deze actie opslaan en dan een rollback kunnen simuleren als je geen data opslaat?

Dat was namelijk waar ik op doelde

code:

history {
  action[cirkel] = [
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
  ]
  action[brush] = [
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
  ]
  action[delete] = [
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
    pixeldata[pixelname, oldcolor, newcolor],
  ]

}

[Clay]

maar als ik bij een rood vak met een zwart randje het rode stuk zwart maak, dan kan je dat volgens mij niet terugroden met een action, aangezien je nu niet meer een vlak met een zwart randje hebt, maar een groter zwart vlak, en met een action zou dan ook de oude rand rood worden als je een floodfill aanspreekt ...

Het principe van actions is trouwens wel gaaf gaar is geen twijfel over, iig bij mij niet.

[drm]

Op donderdag 29 november 2001 16:55 schreef oh,when? het volgende:

[..]

Wat ik me dan afvraag is wat je je dan voorstelt bij een actie? Een actie bestaat uit een handeling die data-verandering tot gevolg heeft. Hoe wil je deze actie opslaan en dan een rollback kunnen simuleren als je geen data opslaat?

Dat was namelijk waar ik op doelde
(..)

dat is dus precies waar je zo'n stack voor aanmaakt

_edit:

Pelle wees drm nog op een foutje, ga ik er even uithalen

[Willem]

Op donderdag 29 november 2001 16:33 schreef drm het volgende:

[..]

* drm heeft iets uitgewerkt. online in a moment...

_edit:

drm's history tracker is done
history test

Heb niet alle errors etc. afgevangen, maar het wijst zichzelf wel, denk ik.

lol

[Clay]

ik bedoel dit:
http://www.xs4all.nl/~peterned/got/pellepaint/

source hier:
http://www.xs4all.nl/~peterned/got/pellepaint/pellepaint.js

[er zit nog een bug in]

[Pelle]

* Pelle kijkt op van z'n leerstof en komt tot de ontdekking dat drm en Clay niet stil hebben gezeten

Doeds, moet jullie niet werken?
Dat van Clay ziet er goed uit; meteen geimplementeerd ook al en dat mag ik altijd wel. Zit echt een beetje in tijdnood nu (ja wie slaapt er dan ook uit tot half 3 als hij een tentamen moet leren ), dus ik ga de source niet doornemen nu, dat doe ik vanavond wel als ik terugkom (uit de kroeg waarschijnlijk... even een vern##kt tentamen vergeten ).

[drm]

Op donderdag 29 november 2001 17:23 schreef Pelle het volgende:
* Pelle kijkt op van z'n leerstof en komt tot de ontdekking dat drm en Clay niet stil hebben gezeten

Doeds, moet jullie niet werken?
Dat van Clay ziet er goed uit; meteen geimplementeerd ook al en dat mag ik altijd wel. Zit echt een beetje in tijdnood nu (ja wie slaapt er dan ook uit tot half 3 als hij een tentamen moet leren ), dus ik ga de source niet doornemen nu, dat doe ik vanavond wel als ik terugkom (uit de kroeg waarschijnlijk... even een vern##kt tentamen vergeten ).

implementeren mag je zelf doen, ik wilde alleen maar een principe duidelijk hebben. Werd er een beetje frusty van

[oh,when?]

Op donderdag 29 november 2001 17:23 schreef Pelle het volgende:
Doeds, moet jullie niet werken?

* oh,when? moet helaas wel werken en kan dus niet aktief iets maken...maar dat doen we vanavond over ICQ wel k?

[Clay]

ik mot ook werken, maar mijn stage = iets met dhtml dus dat zit wel goed.

[Verwijderd]

Is het niet mogelijk om een array in een object te mikken, in plaats van objects in een array?

Met een complete workspace kun je in 1 keer een object clonen, en dus een undo/redo maken. Of is het clonen van een object niet mogelijk met js?

Anti-aliasing van een lijn is volgens mij niet erg moeilijk:

if (afstandTotLijn < 1) pixelkleur = oude kleur + (nieuwe kleur - oude kleur) * (1 - afstand);

Dit werkt per kleur, dus RR GG en BB apart behandelen. Het zou evt. ook bitwise kunnen.

[Oefening]

erg vet hoor
aparte dragable layers misschien een idee (like in ps)? en relatief makkelijk te maken ook nog toch?

[oh,when?]

* oh,when? kan vanavond niet verder werken met pellePaint



kmoet presentatie voorbereiden voor morgen ( Flash 5 XML introductiecursus )

[Pelle]

/ot
* Pelle kan op 't moment even helemaal niks mee...

Tentamen gehad, gezien dat het een inkoppertje was, feestje gebouwd, wijntje gedronken en ergens tussen dat eerste wijntje en nu de tel kwijtgeraakt.... oh wat ga ik me morgen brak voelen

[Clay]

Op donderdag schreef Cheatah:
Met een complete workspace kun je in 1 keer een object clonen, en dus een undo/redo maken. Of is het clonen van een object niet mogelijk met js?

Niet zomaar nee. Als je in js dit doet:

code:

var dinges = new Object();
var danges = dinges;

dan zijn dinges en danges gewoon 1 en hetzelfde ding, die 2e regel doet niets anders dan een referentie leggen naar het object, wat dinges zelf dus eigenlijk ook is.
Een kloon van een object zou je dus volgens mij alleen maar kunnen maken door alle properties uit te lezen en in een nieuw leeg object te stoppen.
Juist omdat dit zo werkt kan je in het pixel object al een referentie leggen naar de layer waar hij bij hoort. Als er een kopie zou ontstaan zou die immers onclick niets tekeken.

Anti-aliasing van een lijn is volgens mij niet erg moeilijk:

if (afstandTotLijn < 1) pixelkleur = oude kleur + (nieuwe kleur - oude kleur) * (1 - afstand);

Dit werkt per kleur, dus RR GG en BB apart behandelen. Het zou evt. ook bitwise kunnen.

Dat bitwise shiften voor rgb truukjes heb ik nou nooit gesnapt, kan iemand dat misschien uitleggen?

[Woudloper]

[..]

Niet zomaar nee. Als je in js dit doet:

code:

var dinges = new Object();
var danges = dinges;

dan zijn dinges en danges gewoon 1 en hetzelfde ding, die 2e regel doet niets anders dan een referentie leggen naar het object, wat dinges zelf dus eigenlijk ook is.
Een kloon van een object zou je dus volgens mij alleen maar kunnen maken door alle properties uit te lezen en in een nieuw leeg object te stoppen.

* Woudloper was over dat klonen van objecten nou net wat aan het lezen op het net.
Het is wel degelijk mogelijk, zie:

Q879 How can I clone or make a copy of an object

Ook las ik daar was over het prototypen van bestaande objecten. Wellicht kan Pelle dat gebruiken als hij toch nog overstapt op Tabelcellen....

[Clay]

ik zei ook niet dat het niet kon

* Clay schreef: Een kloon van een object zou je dus volgens mij alleen maar kunnen maken door alle properties uit te lezen en in een nieuw leeg object te stoppen

en die cloon functie doet dit:

code:

function cloneObject(what) {
   for (i in what) {
      if (typeof what[i] == 'object') {
        this[i] = new cloneObject(what[i]);
      }
      else
        this[i] = what[i];
    }
}

du's da's precies wat ik bedoelde

Prototyping van met en via objecten is idd erg handig ook, voornamelijk als je object inheritance wil maken, maar het is wel de vraag hoe hard je dit nodig gaat hebben. PellePaint is op zich al een voorbeeld van iets waar js niet voor bedoeld is, maar je kan het blijkbaar toch zo ingewikkeld maken als je wil ( misschien is het toch wel zo bedoeld dan? ) Ik zou alleen wel goed nadenken over hoe ingewikkeld je het maken wil.
Ik denk toch dat je bij js (zeker in verband met performance) vaak naar de simpelste oplossing moet zoeken.

[Verwijderd]

Kweenie of je deze al had gezien..?

[Verwijderd]

Op vrijdag 30 november 2001 17:54 schreef ELANAZ het volgende:
Kweenie of je deze al had gezien..?

of deze