It's hard to give an opinion without the possibility to run it... Any download link?
Unfortunately, not yet !
Only beta testers have it but you can ask some features you would have to have.
List of beta testers :
-Barjack
-Beb
-Hal6128
-Kris
Maybe you would get more feedback if you put a beta version publicly available for download because the big thing with a tool is ergonomy, which needs testing.
Actually that's the feature I request! :)
Public version might be Distributed soon. I'm still working on iMPdraw's xmass file system. Stay tuned!
I’m working on my house, so iMPdraw will be back at the end of january,
Sorry for the delay but i want to give you my best.
Nice stuff. But you should translate all this to English, this will increase your user base by the dozens.
First i did the French one! English & others will come later.
French doc took me all my sunday.
And what about a Barjack's Splash Screen to test it ?
Excellent! Why not spread it?
We don't really see how it works! Where are the pixels?
An idea about plugin interface: the plugins shouldn't have to deal with saving/loading.
Instead, they should describe an extension in the header (e.g. SPL), and 'S' would save both "boobs.spl" and "boobs.imp" (only if the image itself has been changed).
« We don't really see how it works! Where are the pixels? »
This first test was done without graphics using pen 0 only.
« An idea about plugin interface: the plugins shouldn't have to deal with saving/loading.
Instead, they should describe an extension in the header (e.g. SPL), and 'S' would save both "boobs.spl" and "boobs.imp" (only if the image itself has been changed). »
Excellent idea. I will do that now. Thanks.
Cool! The main synchronization (VBL / top of screen) shouldn't be in the plugin, but in Impdraw instead.
Impdraw knows where the screen begin, and this position may change in the future.
That being said, the entry point should be at x=0 y=-16 to give some room for potential computation and register loading.
Actually, there should be 2 entry points:
* n: Init (called only once when pressing E). Can be just a RET if there is nothing intensive to do.
* n+3: Frame (called each frame). Maybe pass a parameter: number of lines to display.
(n being the size of the header).
Is keyboard management for Split-Maker done by the plugin itself, or is there some kind of protocol to communicate with ImpDraw2 and reuse some routines?
I did new routines instead of usine i2’s one... but it’s a first step...
Why not releasing alpha/beta versions, with a list of known bugs?
Yours truly,
Would it be possible to have a 'swap inks' function?
I imagine it coded in no time two movements:
* Prepare a 256 translation table, depending on selected pens (color high/low). I can code this part if you wish.
* Apply it!
This table based approach easily allows other functions (change ink, flip bits for H flip, shade in/out).
Putting the code here, since it's useful as well on the fly.
No the fastest, but fast enough, short in memory and working with mode 1 or 0.
genswap
; Create lookup table for pen swap.
; In: hl=table pointer (XX00)
; b = pen X coded as left pixel (e.g. &88 for pen 3 in mode 0)
; c = pen Y coded as left pixel
; Out: Table[N] contains corresponding byte with pen A and B swapped.
; If N contains neither pen A or B, Table[N] = N (unchanged).
ld de,&AA00 ; D = Leftmost mask (&AA for mode 0, &88 for mode 1)
; E = collect pixels
push bc
gs_pixels
ld a,l:and d ; Extract source pixel
cp b:jr nz,gs_notX ; Not pen X, try Y
ld a,c ; Pen X, replace by Y
jr gs_done
gs_notX
cp c:jr nz,gs_done ; Not pen Y either. No change
ld a,b ; Pen Y, replace by X
gs_done
or e: ld e,a
; Next pixel
rrc b
rrc c
rrc d
jr nc,gs_pixels
pop bc
ld (hl),e
inc l
jr nz,genswap
ret
λ
