Looking for a PAINT routine for MSX2

Page 3/4
1 | 2 | | 4

By Dolphin101546015

Master (134)

Dolphin101546015's picture

26-02-2020, 16:03

I has delete src already.
All this not have an meaning, coz real stress test here, is that many pixels in right part.
Basic told you - Memory Overflow on this test, coz his stack memory is over.
My algorithm is shown in the video, uses half less memory, and it is more accurate to use the memory.
It might do this test with twice more resolution 512x212, and even on 512x424, without any promblems, exept one: speed.

On my own test, I get similar results:
256x212 : 6.5 sec (with problem described above)
256x212 : 4.2 sec (without)
512x212 : 18 sec (with problem described above)
512x212 : 8.3 sec (without)
512x424 : 28 sec (with problem described above)
512x424 : 16.1 sec (without)

By pgimeno

Resident (64)

pgimeno's picture

26-02-2020, 17:47

Did you know you can copy stuff then paste to the emulator with the middle mouse button?

It is a memory test, to check what happens when the memory is exhausted, not a speed test. But if the flood fill can escape through the bottom, it's not nearly as effective.

I made a small mistake, anyway, Here's an improved version which also closes that hole:

10 DEFINT A-Z
20 COLOR 15,0,4:SCREEN 2:KEY OFF:CLS
30 LINE (1,0)-(1,95)
40 LINE (1,97)-(1,191)
50 PSET (0,191)
60 LINE (3,49)-(3,143)
70 LINE (5,25)-(5,71)
80 LINE (5,121)-(5,167)
90 FOR I=0 TO 3:LINE (7,13+I*48)-(7,35+I*48):NEXT
100 FOR I=0 TO 7:LINE (9,7+I*24)-(9,17+I*24):NEXT
110 FOR I=0 TO 15:LINE (11,4+I*12)-(11,8+I*12):NEXT
120 FOR I=0 TO 31:LINE (13,2+I*6)-(13,4+I*6):NEXT
130 LINE (15,1)-(255,191),15,BF
140 FOR I=2 TO 190 STEP 2:LINE (15,I)-(255,I),0:NEXT
150 FOR I=16 TO 254 STEP 2:LINE (I,0)-(I,191),0:NEXT
1000 PAINT (0,0)
1010 PRINT INPUT$(1);

Here's GW-BASIC's more advanced flood fill algorithm struggling with it (even without changing the dimensions to match):

By Dolphin101546015

Master (134)

Dolphin101546015's picture

26-02-2020, 18:21

Dude, I use SDCC, and show algorithm in MSX with hardware abilities.
Also you see, what my method done filling several times in MSX? ))
I have in clean MSX Basic too (prog using VDP()), but it slower in degree Smile
PS: but still prety good and able textured filling Wink
This one on video, writed in Assembler, have about 400 bytes of code, and using A, A', HL, BC, DE registers only.
PPS: rly, I don't see any task for filling pattern you presented. Anyway, for such patterns, need another more fast algorithms and some compromises maybe. MSX is machine not for such hard tasks.

By pgimeno

Resident (64)

pgimeno's picture

26-02-2020, 18:52

Well I mean, if the algorithm is included for example in a drawing program, you don't want the drawing program to crash.

By Dolphin101546015

Master (134)

Dolphin101546015's picture

26-02-2020, 20:36

pgimeno wrote:

Well I mean, if the algorithm is included for example in a drawing program, you don't want the drawing program to crash.

This algorithm more for programming and programmers, who know and understand, whats this function require.
If someone wanna write drawing program, he will made controlling of resources maybe.
Think Eric implement some instruments or controls, idk, it his library.
For Eric's Fusion-C, I wrote clean classic algorithm, it fast and small.
I guess he rewrite it in inline Assembler in future.
My own is still closed (I have plans for using it) and does not meet the openness of his library.
Methink nothing bad going, when programmer found restrictions in this function.
So many another functions have it too, so much.
It more like to any compromise between: speed or flexibility, speed or cliping, speed or size and so on.
Fusion-C is slow library for me, but not bad so far.
Moreover, Eric makes many improvements with every new version, and using is very convenient for beginners!
Looks like to some C framework with simplicity of MSX Basic, kinda - MSX Arduino Smile
So it good, if Fusion-C have Paint function now, moreover it my function, and trust me, it fast and convinient for enough.

By gdx

Prophet (3316)

gdx's picture

10-03-2020, 11:37

Dolphin101546015 wrote:

Btw, stock Paint function in MSX2 not working!

It stop painting, coz have bug.

This is not a bug. Paint function in MSX2 use free RAM to store data (at each border encountered put on hold). Paint stops when this area is full. When a Basic program is large, there is not much space left so Paint can stop quickly when the surface to be painted is complex.

By NYYRIKKI

Enlighted (5481)

NYYRIKKI's picture

10-03-2020, 12:47

gdx wrote:

This is not a bug. Paint function in MSX2 use free RAM to store data (at each border encountered put on hold). Paint stops when this area is full. When a Basic program is large, there is not much space left so Paint can stop quickly when the surface to be painted is complex.

If someone is interested, I've made a very simple and small paint that even in worst case use less than 16kB of RAM... Practically only half of that... but it is very slow though.

By Dolphin101546015

Master (134)

Dolphin101546015's picture

10-03-2020, 13:59

gdx wrote:

This is not a bug. Paint function in MSX2 use free RAM to store data (at each border encountered put on hold). Paint stops when this area is full. When a Basic program is large, there is not much space left so Paint can stop quickly when the surface to be painted is complex.

No it wrong. When free memory is over, stock paint exit with error, and basic return - memory overflow.
In this test, no any errors hapen.
And if you looking good, you will see overlapped points, where it will continue working, on the edge of screen.
But function end before.
I know where it have error: MS read VDP registers wrong, and therefore observer ignore last coordinate.

By Dolphin101546015

Master (134)

Dolphin101546015's picture

10-03-2020, 14:10

NYYRIKKI wrote:

If someone is interested, I've made a very simple and small paint that even in worst case use less than 16kB of RAM... Practically only half of that.

My code in last example using about 3kb.
Also I have modyfied, where faster method using 1.5 kb for G4 (G7) modes, and 3kb for G5(G6) worst case,
And get about 500 bytes for 16 bit algorithm (G6,G7), and ~400 for G4,G7 (G9, G10, G11)

Function what got Eric is universal for any graphic modes.

By Dolphin101546015

Master (134)

Dolphin101546015's picture

10-03-2020, 14:15

Also above I wrote about strange behavior in OpenMSX. Eric made needed tests on real hardware and got same results.
It give strange dergadation of speed, in left part of screen, and delay concluded in waiting cycle of search function.
This dergadation not so big actualy, and we decided stay it as it working.

Page 3/4
1 | 2 | | 4