sprite editor

[bplus]

Performed an experiment... To draw a grid of 64x64 the gsize is set to 10 (64X10 =gridwidth). Likewise setting gsize to 20 etc etc.

In the plot() routine the 'size' is hard coded to 10 (64x64). Changed '10's to gsize. Hard coded gsize to 20 and a 32x32 grid was drawn... Hard coded to 40 - 16x16 grid. Coded to 80 - 8x8 grid.

Checked all the tools. Pencil, Line, Frame and Box performed correctly. Ovals (also fill)... Not so much. The other tools took advantage of plot(), which resized exactly, but the ellipses are drawn with the line()-() command. Single sized line. Ovals and filled ovals will still draw on all grid sizes, but because the line is a single thickness, the lines do not match the grid. See attached

The attached was hard coded to a gsize of 40 (16x16)

Another issue are the preview boxes. They also would need 'scaling'.  64x64 and 32x32 seem to be ok. The smaller grids seem to be an issue.

Right, I made the drawing tools leaving open the idea we will want to do squares of any size, including n X m rectangles eventually, just wanted to get one set working first. You can fix Plot4Way just as easy as Plot for the circle ellipse tools. I was also thinking with dot tool we could set a radius so we have a perfect circle fill. I don't know if you  noticed but ellipse /oval are drawn with 4 pixel = squares center and the left side gets shifted in alignment over a bit from the ellipse drawn while mouse button is down showing general placement of ellipse.

BTW Last night I had a wild and crazy idea, why don't we use Spr Draw to make our drawing tools icons?!?!

[johnno56]

Well, you were correct, of course. Modifying plot4way did indeed solve the grid problem.

To change the the grid size, either by keyboard or button, would not be practical if one was in the midst of a project. I would dare to suggest that there are two opportunities to change the grid. 1. When the program starts and 2. When "New" is selected. I will the simplest option, keyboard 1 to 4, for 8x8 to 64x64... Sounds like fun...

Use sprdraw to make our own icons... At the moment, as long as the icons were squares, like the ones in the toolbox. No. I don't think that is a crazy idea. Our regular buttons are 80x40, slightly out of the range of the editor, but who said the buttons had to be rectangular? lol To keep similar button spacing, 40x40 could be possible... By changing gsize to 16...  Which I just tried and the grid size indeed changed to 40x40... :)

I will re-draw the "buttons", using sprdraw, to 40x40... Of course there will be no transparency... lol  Not a big deal at the moment... Seeing the background is black anyway... lol  This morning (Sunday) is quite busy for us, so it could be around noon before I can find the time. Just though of another function... 'Move'. When I was creating the last 'screenshot' I would have to draw, erase, redraw the ellipses. It's more of a time saver on larger icons really. Just a thought. Not sure why I thought of that at that particular time... 'Move' isn't important... Just an idea... Must remember the program was initially designed to do pixel art... Sprites and stuff...If we add too much then it becomes a Photoshop wanna-be.... lol Sorry. No coffee yet...

[bplus]

Hey @johnno56

What's wrong with buttons at 64X64? Just happens to be the size we have working now. Or do you already have any size working? I mean what's so special about 40?

It is not hard to draw a whole grid of 64x64 or any n X m buttons, have a tool belt that looks like a metal jacket.

hmm... to make draw objects to move around or manipulate, I like!

Oh yeah, for sizing grids just start a standard of loading and saving as "*NXM.png" where N and M are two numbers so we can read the grid size off the filename. Might be a limit to the size M and N though.

Oh and for transparency, we can read something else in file name a color code maybe to set the _CLEARCOLOR to that color and that color will be converted in a little sub so that color will be transparent when used in QB64.

[Dav]

Hey, this project is looking pretty neat!  I'll be following it.  I'm always interested in doodling programs. 

- Dav

[johnno56]

Bplus,

Absolutely nothing wrong with 64x64. 40x40 special? Nope. Just the same height as the existing buttons and would not take much to modify their placement. As we don't have too many 'active' buttons at the moment, 64x64 buttons, will work just fine. MSPaint uses small square image buttons. Gimp (and I think Photoshop) uses an 'area' populated with clickable images. We already use rectangular buttons. I will try to make a 'mockup' of an 'area' of images.  See the 'area' that Gimp uses... Of course, we do not have as many tools, but it's the idea of the layout...

[johnno56]

Just threw together a vertical 'tree' of tool icons (40x40). It's easy enough to bump them up to 64x64.

If you have any ideas on layouts, just let me know, and I'll whip up a new batch....

[bplus]

I was just going to say, I had another look at those Toolbox buttons and they looked OK too.

You make the call on buttons, I am going to try and get that file retriever to have both lists going at once.

Also do you have doing the different gsizes worked out?

[johnno56]

In reference to gsizes... So far all I have is hard coding. But, there are issues with previews. I need to look at scaling the image, for different main grid sizes, to occupy the entire preview window. If I hard code the the gsize (80) to display an 8x8 main grid, the preview image, is just a tiny copy in the upper left corner of the preview. As, saving and loading requires 'scanning' of the small preview, if would be best if the entire preview window is occupied. I hope I am making sense...

[johnno56]

I don't mean to harp on this... The attached images will give you an idea of the preview issue.
The main grid (10x10) contains a filled 10x10 oval. The main grid is translated to the preview box. The preview box image is the image saved. When the saved image (with the tiny oval in the top left corner) is loaded, it is placed in the preview box and translated back to the main grid. The main grid will display a small oval in the top left corner.

Any ideas?

[bplus]

I don't mean to harp on this... The attached images will give you an idea of the preview issue.
The main grid (10x10) contains a filled 10x10 oval. The main grid is translated to the preview box. The preview box image is the image saved. When the saved image (with the tiny oval in the top left corner) is loaded, it is placed in the preview box and translated back to the main grid. The main grid will display a small oval in the top left corner.

Any ideas?

Yes, that is why we need to save the the N X M grid size in the file name and offer grid size input when start a new image or loading some part of an image. Then track down every place that uses gsize or 10 for gsize and change all that from const gsize to Dim Shared gSize or 2: gSizeX and gSizeY if you want to graduate from squares.

The trickiest part is tacking a N X M.png onto the end of the filename. I am just saying .png to get one extension going , could be jpg or .bmp.  What character will Linux take in file name that we can use to separate Name part from number part $? So it would be "Filename$64x32.png" for a 64 x 32 image grid

Then we can read gSizeX = 64 and gSizeY = 32 and adjust those variables and then draw our grid and run the code from there. So yeah, if we start a new image the file name will have to be setup, thank goodness we have an inputBox sub or function (I forgot).

BTW I don't know well numbers not divisible by 2 will work or if we should mess with different x and y sizes.

I'd say get the buttons nailed down first. I hope to have 2 lists going in file retriever then start on grid size problem.
If you use a grid of buttons, you can tell which one is clicked just like you can tell which grid cell is clicked on the grid, it's just a different grid with different grid sizes.

[bplus]

Hey, this project is looking pretty neat!  I'll be following it.  I'm always interested in doodling programs. 

- Dav

Thanks Dav, your input welcome! :)

A little reminder, Johnno has Linux and we can't use normal Windows tools for things.

[SMcNeill]

If you guys want my simple take on how I'd set this project up and work with it, I'd go with a main layout similar to something like this:

Code: QB64: [Select]

1. MainScreen = _NEWIMAGE(1024, 720, 32)
2. ZoomLevel = 16
3.  
4. SCREEN MainScreen
5.  
6.  
7. DO
8.     CLS , 0
9.  
10.     DrawGrid ZoomLevel
11.     WHILE _MOUSEINPUT
12.         SELECT CASE _MOUSEWHEEL
13.             CASE IS > 0: ZoomLevel = ZoomLevel * 2: IF ZoomLevel > 512 THEN ZoomLevel = 512
14.             CASE IS < 0: ZoomLevel = ZoomLevel \ 2: IF ZoomLevel < 1 THEN ZoomLevel = 1
15.         END SELECT
16.     WEND
17.  
18.  
19.     LOCATE 1, 80: PRINT "GRID SIZE :"; 512 \ ZoomLevel; "X"; 512 \ ZoomLevel
20.     LOCATE 2, 80: PRINT "PIXEL SIZE:"; ZoomLevel; "X"; ZoomLevel
21.     _LIMIT 30
22.     _DISPLAY
23. LOOP UNTIL _KEYHIT = 27
24.  
25.  
26. SUB DrawGrid (ZoomLevel)
27.     FOR i = 0 TO 512 STEP ZoomLevel
28.         LINE (i, 0)-STEP(0, 512)
29.         LINE (0, i)-STEP(512, 0)
30.     NEXT
31. END SUB

The concept here is rather simple:  Load any sort of image which you want and work with it inside a fixed 512x512 screen area.  (Add a simple set of scroll bars to the side, if you need to see more than that area at any given time.)

The default resolution which we work at is a 32x32 grid area, of 16x16 pixels, for ease of selecting and editing, but it can be easily zoomed in, or zoomed out, as we desire -- to between a 512x512 grid of 1x1 pixels, up to a 1x1 grid of 512x512 pixels.  (The demo here showcases the zoom feature, and shows how easy you can implement it.)

All your mouse needs to do is convert any clicks you make upon the grid into coordinates for the original, unscaled image, and then apply your changes there.

Like this, you can easily work with any sort of sprite size, and at various levels of zoomability, to have your editor working with whatever images/sprites, you want to create.  ;)

[bplus]

If you guys want my simple take on how I'd set this project up and work with it, I'd go with a main layout similar to something like this:

Code: QB64: [Select]

1. MainScreen = _NEWIMAGE(1024, 720, 32)
2. ZoomLevel = 16
3.  
4. SCREEN MainScreen
5.  
6.  
7. DO
8.     CLS , 0
9.  
10.     DrawGrid ZoomLevel
11.     WHILE _MOUSEINPUT
12.         SELECT CASE _MOUSEWHEEL
13.             CASE IS > 0: ZoomLevel = ZoomLevel * 2: IF ZoomLevel > 512 THEN ZoomLevel = 512
14.             CASE IS < 0: ZoomLevel = ZoomLevel \ 2: IF ZoomLevel < 1 THEN ZoomLevel = 1
15.         END SELECT
16.     WEND
17.  
18.  
19.     LOCATE 1, 80: PRINT "GRID SIZE :"; 512 \ ZoomLevel; "X"; 512 \ ZoomLevel
20.     LOCATE 2, 80: PRINT "PIXEL SIZE:"; ZoomLevel; "X"; ZoomLevel
21.     _LIMIT 30
22.     _DISPLAY
23. LOOP UNTIL _KEYHIT = 27
24.  
25.  
26. SUB DrawGrid (ZoomLevel)
27.     FOR i = 0 TO 512 STEP ZoomLevel
28.         LINE (i, 0)-STEP(0, 512)
29.         LINE (0, i)-STEP(512, 0)
30.     NEXT
31. END SUB

The concept here is rather simple:  Load any sort of image which you want and work with it inside a fixed 512x512 screen area.  (Add a simple set of scroll bars to the side, if you need to see more than that area at any given time.)

The default resolution which we work at is a 32x32 grid area, of 16x16 pixels, for ease of selecting and editing, but it can be easily zoomed in, or zoomed out, as we desire -- to between a 512x512 grid of 1x1 pixels, up to a 1x1 grid of 512x512 pixels.  (The demo here showcases the zoom feature, and shows how easy you can implement it.)

All your mouse needs to do is convert any clicks you make upon the grid into coordinates for the original, unscaled image, and then apply your changes there.

Like this, you can easily work with any sort of sprite size, and at various levels of zoomability, to have your editor working with whatever images/sprites, you want to create.  ;)

This gives me some ideas to test.

[SMcNeill]

This gives me some ideas to test.

Give this little demo a quick test and see if it's not about what you'd be wanting for your sprite editor:

Code: QB64: [Select]

1. DIM SHARED StartX, StartY, CurrentX, CurrentY, StopX, StopY, EndX, EndY
2. DIM SHARED EditScreen
3.  
4. MainScreen = _NEWIMAGE(1024, 720, 32)
5. EditScreen = _LOADIMAGE("wood.jpg", 32)
6. ZoomLevel = 16
7.  
8. SCREEN MainScreen
9. CurrentX = 0: CurrentY = 0
10.  
11.  
12. DO
13.     CLS , 0
14.  
15.     _PUTIMAGE (0, 0)-(511, 511), EditScreen, MainScreen, (CurrentX, CurrentY)-STEP(512 \ ZoomLevel - 1, 512 \ ZoomLevel - 1)
16.     DrawGrid ZoomLevel
17.     WHILE _MOUSEINPUT
18.         SELECT CASE _MOUSEWHEEL
19.             CASE IS > 0: ZoomLevel = ZoomLevel * 2: IF ZoomLevel > 512 THEN ZoomLevel = 512
20.             CASE IS < 0: ZoomLevel = ZoomLevel \ 2: IF ZoomLevel < 1 THEN ZoomLevel = 1
21.         END SELECT
22.     WEND
23.     k = _KEYHIT
24.     SELECT CASE k
25.         CASE 27: SYSTEM
26.         CASE 19200: CurrentX = CurrentX - 1: IF CurrentX < 0 THEN CurrentX = 0
27.         CASE 19712: CurrentX = CurrentX + 1: IF CurrentX > StopX THEN CurrentX = StopX
28.         CASE 18432: CurrentY = CurrentY - 1: IF CurrentY < 0 THEN CurrentY = 0
29.         CASE 20480: CurrentY = CurrentY + 1: IF CurrentY > StopY THEN CurrentY = StopY
30.     END SELECT
31.  
32.     LOCATE 1, 80: PRINT "GRID SIZE :"; 512 \ ZoomLevel; "X"; 512 \ ZoomLevel
33.     LOCATE 2, 80: PRINT "PIXEL SIZE:"; ZoomLevel; "X"; ZoomLevel
34.     LOCATE 3, 80: PRINT "X/Y START :"; CurrentX, CurrentY
35.     LOCATE 4, 80: PRINT "X/Y END   :"; CurrentX + 512 \ ZoomLevel, CurrentY + 512 \ ZoomLevel
36.     LOCATE 6, 80: PRINT "PIC SIZE  :"; _WIDTH(EditScreen), _HEIGHT(EditScreen)
37.     LOCATE 7, 80: PRINT "X/Y STOP  :"; StopX, StopY
38.  
39.     _LIMIT 30
40.     _DISPLAY
41. LOOP
42.  
43.  
44.  
45.  
46. SUB DrawGrid (ZoomLevel)
47.     EndX = _WIDTH(EditScreen)
48.     EndY = _HEIGHT(EditScreen)
49.     StopX = EndX - 512 \ ZoomLevel
50.     StopY = EndY - 512 \ ZoomLevel
51.     FOR i = 0 TO 512 STEP ZoomLevel
52.         LINE (i, 0)-STEP(0, 512), _RGBA(64, 64, 64, 64)
53.         LINE (0, i)-STEP(512, 0), _RGBA(64, 64, 64, 64)
54.     NEXT
55. END SUB

This should work with any image file, but I attached the one I was using.  (Which I think was one Cobalt provided for one of his game demos, and I hadn't cleaned it out yet?)

There's no actual selection of anything yet, and I haven't bothered to convert any sort of mousex/mousey input to make it useful, but I think this goes a long ways towards highlighting how I'd work up an image editor with built-in zoomability functionality. 

Honestly, I can't imagine any way to work with something like this, any simpler than the above.  Our sprite/image is always separate from the main program (EditScreen), so we're not tracking pixels, or an array of information, or anything like that.  All we do is convert the coordinates, and the command we want, and we apply it directly to the image in question.  When finished, simply save that image with the SaveImage library.  :)

Test it out.  See if the little demo here isn't doing about what you'd want it to do.  Here's to hoping it'll help spark all sorts of nice ideas for you guys to add into your own work-in-progress.  ;D


NOTE:  As I'm lazy and haven't implemented scrollbars just for a demo, use the arrow keys to navigate around in your image. 

[bplus]

Hi Steve,

I was thinking about something like that when loading images to work in the editor. If we can scan over an image at various zoom levels and pickup some section to workup in the editor...

I am in middle of 2nd massive over haul actually making it easier to modify buttons, maybe. With a 512 grid I reduced screen width to 1024, and moved things around and have a ton of room for more buttons. All this could be giant waste of time if I can't rework all the tools to different gSizes, just about getting to that now.