RetroBASIC
Basicprogramming(.org) => Code and examples => Topic started by: Cybermonkey on February 28, 2016, 06:44:42 PM
-
I ported one of the examples from Stephen's page (http://shawweb.myzen.co.uk/stephen/sdlbasic.htm) to AllegroBASIC:
import "keycodes.bas"
screen (800,600,"Randomize Overlaid Circles")
srnd (val(right(time,2)))
TEXTSIZE (2)
SIDE=15
do
cls
FOR I=1 TO SCREENWIDTH
FOR J=1 TO SCREENHEIGHT
X=I*SIDE/600
Y=J*SIDE/600
C=FIX(X*X+Y*Y)
D=C/2
IF D-FIX(D)<0.11 THEN
PSET (I+1,J+1)
ENDIF
NEXT
IF WINDOWCLOSED=TRUE THEN END
REDRAW
NEXT
INK (0,0,0)
fillrectangle (0,0,screenwidth,40)
INK (255,255,255)
DRAWTEXT (0,0,"ESC to end, R for random new one, S to zoom back")
DRAWTEXT (0,20, "to start, any other to zoom out.")
SYNC
SIDE=SIDE*1.15
INKEY
SRND (TICKCOUNT)
IF KEYSTATE (KEY_R) THEN
SIDE=FIX(RND*160)+1
ENDIF
IF KEYSTATE (KEY_S) THEN
SIDE=15
ENDIF
INK (255,255,255)
until (keystate (KEY_ESC)=true) or (windowclosed=true)
END
-
I just learned that there was also a (much shorter) Simons' BASIC example for the Commodore 64. I ported this for CBR-BASIC (details will follow soon), as shown in the screenshots.
-
So that's where Peter W got that code...
Well here is colorized version posted some time ago.
'pattern.bas for SmallBASIC 0.12.0 2015-11-27 Peter W & MGA/B+
'pixel version
f=4 '<================== 1 to 8? speed, the faster the less fine
s=500
while 1
for i=0 to xmax/f
for j=0 to ymax/f
x=i*s/600
y=j*s/600
c= x*x+y*y
d=c/2
d=d-int(d)
if d <0.25 then
cc=rgbf(d*4,0,0)
elif d<.5
cc=rgbf(0,2*d,0)
elif d<.75
cc=rgbf(0,0,4/3*d)
else
cc=0
fi
rect i*f,j*f step f,f,cc filled
'pset i,j,cc
next
next
showpage
pause 'for snapshot
s+=5
if s>1000 then s=5
wend
-
This is my SDL_gfx circle demo.
' ScriptBasic GFX - Alpha Circles
IMPORT gfx.inc
scrn = gfx::Window(640, 480, "ScriptBasic GFX - Alpha Circles")
' Random Value Arrays
RANDOMIZE(gfx::Time())
FOR i = 0 TO 512
rx[i] = RND() % 640
ry[i] = 60 + RND() % 480 - 80
rz[i] = RND() % 64
rr[i] = RND() AND 255
rg[i] = RND() AND 255
rb[i] = RND() AND 255
af = rx[i] / 640
ra[i] = INT(255 * af)
NEXT
ts = gfx::Time()
FOR i = 0 TO 512
gfx::filledCircleRGBA scrn, rx[i], ry[i], rz[i], rr[i], rg[i], rb[i], ra[i]
NEXT
te = gfx::Time()
gfx::stringColor scrn, 20, 15, "Time: " & FORMAT("%.4f",(te-ts)/1000) & " Seconds." & CHR(0), 0xffffffff
gfx::Update
WHILE gfx::KeyName(1) <> "+escape"
WEND
gfx::Close
(http://files.allbasic.info/ScriptBasic/gfx/gfx_alpha_circles.png)
-
Really not random at all!
http://shawweb.myzen.co.uk/stephen/sdlbasic.htm
-
Really not random at all!
Hugh?
The circle(s) size, position, color and alpha channel are randomized.
-
Really not random at all!
Hugh?
The circle(s) size, position, color and alpha channel are randomized.
Not your code, the original code from which Cyb sourced, the Connett Circles. They are not really random.
A random number generator (RND) is never used except to setup different screen shot.
-
Here is SmallBASIC code rectangles translated to Naalaa pixels for exe:
'patterns.txt Naalaa [B+=MGA] from
'pattern.bas for SmallBASIC 0.12.0 2015-11-27 Peter W & MGA/B+
'pixel colorized version
constant:
xmax = 800
ymax = 600
hidden:
set window 100, 40, xmax, ymax
set redraw false
s# = 500.0
while 1
set colori 0xffffff
cls
set colori 0
for y = 0 to ymax
for x = 0 to xmax
a# = float(x) * s / 600.0
b# = float(y) * s / 600.0
c# = a# * a# + b# * b#
d# = c# / 2.0
d# = d# - float(int(d#))
if d# < 0.25
r = int(d# * 4.0 * 255.0)
set color r, 0, 0
elseif d# < 0.5
g = int(d# * 2.0 * 255.0)
set color 0, g, 0
elseif d# < 0.75
bl = int(d# * 4.0 / 3.0 * 255.0)
set color 0, 0, bl
else
set color 0, 0, 0
endif
draw pixel x, y
next
next
redraw
wait 200
if keydown(27, true) then end
s# = s# + 5.0
if s# > 1000.0 then s# = 5.0
wend
Nothing random about it!
-
BaCon pixel version where I have tried to stick to the original code as much as possible.
'pattern.bas for SmallBASIC 0.12.0 2015-11-27 Peter W & MGA/B+
'pixel version
'ported to BaCon by PvE - sep 2016 - use '-z' option to compile small letters
include canvas-gd.bac
option vartype double
window("Pattern",800,600)
f=1 : '<================== 1 to 8? speed, the faster the less fine
s=500
for frame=1 to 16
for i=0 to WIDTH/f
for j=0 to HEIGHT/f
x=i*s/600
y=j*s/600
c= x*x+y*y
d=c/2
d=d-round(d)
if d <0.25 then
ink(d*4,0,0,255)
elif d<.5 then
ink(0,2*d,0,255)
elif d<.75 then
ink(0,0,4/3*d,255)
else
cc=0
fi
'rect i*f,j*f step f,f,cc filled
'pset i,j,cc
pixel(i,j)
next
next
sync
delay(500) : 'for snapshot
incr s,5
if s>1000 then s=5
next
(http://www.basic-converter.org/canvas/Pattern.gif)
-
Python (using graphics.py):
from graphics import *
xmax = 800
ymax = 600
win = GraphWin('Circles', xmax, ymax)
win.autoflush = False
win.getMouse()
while 1:
s = 500
for x in range(0, xmax + 1):
for y in range(0, ymax + 1):
a = x * s / 600.0
b = y * s / 600.0
c = a * a + b * b
d = c / 2.0
d = d - int(d)
if d < 0.25:
kol = color_rgb(d * 4, 0, 0)
elif d < 0.5:
kol = color_rgb(0, 2 * d, 0)
elif d < 0.75:
kol = color_rgb(0, 0, 4 / 3.0 * d)
else:
kol = color_rgb(255, 0, 0)
win.plot(x, y, kol)
print x
win.flush()
win.getMouse()
if s == 1000:
s = 500
else:
s += 5
-
Thanks Tomaaz, I've yet to figure out graphics on Python, PyGame is disaster! :(
Anyway, although I like red allot, the SmallBASIC code from which you are coloring with d numbers was using RGBF scales not RGB.
To translate RGBF to RGB, multiply by 255 as all RGBF numbers run from 0 to 1, or 0 % to 100% of 255
Append:
Tomaaz code defaults to red in the else section, I have no idea how Peter is getting red in his snapshots.
-
Thanks Tomaaz, I've yet to figure out graphics on Python, PyGame is disaster! :(
Pygame may seem a bit complex and bloated for someone who comes from BASIC (or EGSL or NaaLaa) background. If you want to start with graphics in Python, have a look at:
graphics.py
It's based on Tkinter and very easy to use. Works with Python2, 3 and PyPy (JIT compiler for Python).
Website, download + documentation (http://mcsp.wartburg.edu/zelle/python/)
Alternative documentation (http://anh.cs.luc.edu/python/hands-on/3.1/handsonHtml/graphics.html)
GASP
I've been using it only with Python 2 as it is aviable in Ubuntu's reposirories. It's a bit outdated but still works and can be used for learning.
Tutorial (http://www.openbookproject.net/pybiblio/gasp/course/G-gasp.html)
Processing.py
This is a Python version of Processing (that is based on Java). It comes with a dedicated IDE (the same Processing comes - you just need to add Python mode to it).
Website (http://py.processing.org/)
Turtle
A Python implementation of classic Logo language. It's based on Tkinter. Extremely easy to use.
Turtle (https://docs.python.org/2/library/turtle.html)
Sorry about a little bit of off-topic. ;)
-
Oh for Windows and graphics, don't start IDLE from Start Menu! Hmm... that may explain some of my problems.
Thanks Tomaaz!
-
Hehe, may I boast a little? :)
Here's the same on the FBSL GDI Canvas, cleaned of some dead code that's hiding in the original, as I'm seeing it in my editor:
#AppType Console // use console to examine listing
#Option Implicit // don't declare variables
#Include "Canvas.inc"
With Canvas
.Window("Interference", 400, 300)
.Font("Baccarat", 24, 1)
.ForeColor(0, 255, 255)
Do
s = 500
For frame = 1 To 16
For i = 0 To .Width
For j = 0 To .Height
x = i * s / 600
y = j * s / 600
c = x ^ 2 + y ^ 2
d = c / 2
d = d - Round(d)
.PSet(i, j, RGB(4 * d, 0, 0))
Next
If Not .hWnd Then Exit Do
Next
.Write(10, 10, "Great Vibes!")
.Refresh()
Wait(200)
If Incr(s, 5) > 1000 Then s = 5
Next
Loop
End With
and the attached image shows how the listing would look in the console (i.e. if the #AppType Console mode is active) when run from its original .FBS file (Windows) and a precompiled .EXE (Ubuntu and Mac OS X Wine) if the .EXE isn't exepacked, or password-protected, or both. If it is then the listing won't be seen at all but the code will still run. The .EXE that's attached in the zip below is neither exe-packed nor protected, so its console output will be similar to Wine. The differences are due to the .EXE listing being actually decompiled on the fly from the .EXE itself where its formatting and indentation are minimized and all the PP macros, if any, are already resolved to literals. In the default #AppType GUI mode the listing is of course unavailable.
As it happens, a 800x600 pxs window is a bit too much for FBSL BASIC's interpreted PSet() so my window is smaller but responsive and fast, albeit still a little CPU intensive. As I said, I'm developing my Canvas based on your examples, so if I ever need to fill its entire surface with triply nested PSet() loops again, I will have to add a BASIC-to-C translator to the CCanvas class to go fully DynC JIT compiled. ;D
-
I will have to add a BASIC-to-C translator to the CCanvas class to go fully DynC JIT compiled.
That would be cool!
Nice job adding the text feature to your CCanvas class.
-
I will have to add a BASIC-to-C translator to the CCanvas class ...
That would be cool!
Would it? ;)
-
I was messing around with this one a while ago in SpecBAS - runs in 8bpp, with colour cycling to animate:
10 DEF FN r=INT(RND*5)*63.9: b=1 SHL (INT(RND*5)+2),p,op=0: DO: PALETTE p,FN r,FN r,FN r: RAINBOW op TO p: op=p,p+=b: LOOP UNTIL p=256: PALETTE 255,RGB 0: RAINBOW op TO 255: r=RND*3: SCREEN LOCK
20 p=WINADDR 0: FOR y=0 TO SCRh-1: ym=y*y: FOR x=0 TO SCRw-1: MEMWRT p,(POWERTWO x+ym)*r: p+=1: NEXT x: NEXT y
30 DO WHILE INKEY$="": PALETTE SHL 1,0 TO 255: WAIT SCREEN: LOOP: GO TO 10
And more readable:
10 DEF FN r=INT(RND*5)*63.9:
b=1 SHL (INT(RND*5)+2),p,op=0:
DO:
PALETTE p,FN r,FN r,FN r:
RAINBOW op TO p:
op=p,p+=b:
LOOP UNTIL p=256:
PALETTE 255,RGB 0:
RAINBOW op TO 255:
r=RND*3:
SCREEN LOCK
20 p=WINADDR 0:
FOR y=0 TO SCRh-1:
ym=y*y:
FOR x=0 TO SCRw-1:
MEMWRT p,(POWERTWO x+ym)*r:
p+=1:
NEXT x:
NEXT y
30 DO WHILE INKEY$="":
PALETTE SHL 1,0 TO 255:
WAIT SCREEN:
LOOP:
GO TO 10
Line 10 sets up a palette, line 20 draws the Moire pattern, line 30 sits cycling the colours waiting for a keypress.
Screengrabs (though the animation obviously isn't shown here and certain structures don't show up in static images) :
(https://s17.postimg.io/3qpy9zpsf/moire1.png)
(https://s17.postimg.io/rvqnrpa33/moire2.png)
(https://s17.postimg.io/a6yx02ybz/moire3.png)
-
Wow, that's cool, Paul!
To translate RGBF to RGB, multiply by 255 ...
Done, thnx!
-
Testing new update of SmallBASIC, I found I hadn't expressed full range for G and B colors so here is that "fix" with an R or G or B full intensity palette plus a bunch of key or mouse navigation of s range 0 to 995 and color on/off toggle and +- magnifications.
' patterns 2.bas SmallBASIC 0.12.7 [B+=MGA] 2016-09-18
' from pattern.bas for SmallBASIC 0.12.0 2015-11-27 Peter W & MGA/B+
' 2016-09-18 modify (Fix!) to full range R OR G OR B coloring
' test new 0.12.7 update SmallBASIC (2016-09-17)
' add toggles for rectangles 1 to 8 with + for plus, - for minus
' add toggles c for color to B & W
' add keys u, d, h, e for like: page up, page down, home, end
' add label, extra code to speed B&W versions
definekey 43, plusPress ' + increase reactangle size up to 8x8 pixels
definekey 45, minusPress ' - decrease rectangle size to 1x1 = pixels
definekey 99, cPress 'color toggle B&W
definekey 98, bPress 'b for back 5, s back 5 = last s again
definekey 117, uPress 'u like page up, s + 100, also click right screen
definekey 100, dPress 'd like page down, s - 100, also click left screen
definekey 104, hPress 'h like home, s = 10 , also click top screen
definekey 101, ePress 'e like end, s = 900, also click bottom screen
colr = 1 'color is on
g = 2 'g controls f the rectangle size
u = 500 'u controls s that controls the d number that controls color
pen on
while 1
cls
f = g
s = u
if colr then
for i = 0 to xmax / f
for j = 0 to (ymax - 20) / f
x = i * s / 600
y = j * s / 600
c = x * x + y * y
d = c / 2
d = d - int(d)
if d < .35 then
cc = rgbf(d / .35, 0, 0)
elif d < .7
cc = rgbf(0, (d - .35) / .35, 0) 'get full range %
else
cc = rgbf(0, 0, (1 - d) / .30000001) 'get full range %
fi
rect i * f,j * f + 21 step f, f, cc filled
'pset i,j,cc
next
next
else
for i = 0 to xmax / f
for j = 0 to (ymax - 20) / f
x = i * s / 600
y = j * s / 600
c = x * x + y * y
d = c / 2
d = d - int(d)
if d < 0.35 then rect i * f, j * f + 21 step f, f, 15 filled
next
next
end if
color 7, 0
ts = "Patterns 2: s = " + str(s) + ", " + str(f) + "x"
ts = ts + str(f) + " key: + - pixel magnification, c color on/off, b backup,"
ts = ts + " u d h e or click to naviagte s"
at (xmax -txtw(ts))/2, 1 : ? ts
showpage
pause 'for snapshot
if pen(3) then
mx = pen(4) : my = pen(5)
delay 100
if my > 100 and my < ymax - 100 then
if mx < 100 then dPress
if mx > xmax - 100 then uPress
elif my < 100 and my > -1
hPress
elif my > ymax - 100
ePress
end if
end if
u += 5
if u > 1000 then u = 5
wend
sub plusPress()
g = iff(f + 1 < 9, f + 1, f)
end
sub minusPress()
g = iff(f - 1 > 0, f - 1, f)
end
sub cPress()
colr = (colr + 1) % 2
end
sub bPress()
u = iff(u - 10 > 0, u - 10, 990)
end
sub uPress()
u = iff(u + 100 < 1000, u + 100, 900)
end
sub dPress()
u = iff(u - 100 > 0, u - 100, 5)
end
sub hPress()
u = 5
end
sub ePress()
u = 900
end sub
-
One more?
-
One more?
Oh yeah, I guess somebody might call yet more latent reserves to the colours... ;D
Are you using rects to speed up drawing?
-
One more?
Oh yeah, I guess somebody might call yet more latent reserves to the colours... ;D
Are you using rects to speed up drawing?
The first patterns versions was already using rectangles, and yes that can dramatically speed drawings by cutting down number of pixels to cycle through.
The speed up in this version is for B&W, with color option off, only have to draw 35% of rectangles at any size after a clear screen.
Here is an 8 color scheme, 3 primaries + 3 secondaries + 2 for B&W (for those who appreciate exquisite detail) 0 to 1 is split into 6 color ranges, 65 to 255, plus 1/8th pure black and 1/8th pure white for contrast:
'patterns 8 color range.txt Naalaa [B+=MGA] from
'pattern.bas for SmallBASIC 0.12.0 2015-11-27 Peter W & MGA/B+
'pixelated colorized version
'2016-09-18 mod fix color range now 6 primary and secondary & B&W
constant:
xmax = 800
ymax = 600
hidden:
set window 100, 40, xmax, ymax
set redraw false
s# = 500.0
while 1
set colori 0xffffff
cls
set colori 0
for y = 0 to ymax
for x = 0 to xmax
a# = float(x) * s / 600.0
b# = float(y) * s / 600.0
c# = a# * a# + b# * b#
d# = c# / 2.0
d# = d# - float(int(d#))
if d# < 0.125
set color 0, 0, 0
elseif d# < 0.25
r = int((d# - 0.125) / 0.125 * 190.0 + 65.0)
set color r, 0, 0
elseif d# < 0.375
r = int((d# - 0.25) / 0.125 * 190.0 + 65.0)
set color r, r, 0
elseif d# < 0.5
g = int((d# - 0.375) / 0.125 * 190.0 + 65.0)
set color 0, g, 0
elseif d# < 0.625
g = int((d# - 0.5) / 0.125 * 190.0 + 65.0)
set color 0, g, g
elseif d# < 0.75
bl = int((d# - 0.625) / 0.125 * 190.0 + 65.0)
set color 0, 0, bl
elseif d# < 0.875
bl = int((d# - 0.75) / 0.125 * 190.0 + 65.0)
set color bl, 0, bl
else
set color 255, 255, 255
endif
draw pixel x, y
next
next
redraw
wait 200
if keydown(27, true) then end
s# = s# + 5.0
if s# > 1000.0 then s# = 5.0
wend
-
Thnx!
What does j * f + 21 step f mean?
-
Thnx!
What does j * f + 21 step f mean?
Referring to SmallBASIC code Along with:
for j = 0 to (ymax - 20) / f
It means that there is no sense calculating and drawing in a place over which you are going to print a label.
The label is going to lay between y = 0 to 20 so I am starting the drawings below that.
That would keep consistent the top, left corner of a drawing in any dialect for a given s setting.
As I have said, not random at all, no matter the dialect the same results can be replicated, if you can match palettes, top, left corner, rectangle size and of course s value +/- some rounding methods and decimal precision.
Append: Oh step f, f while drawing rects
SmallBASIC has some options using rect keyword. Without STEP, it's just absolute coordinates for corners.
With STEP and first corner x,y it means width and height as used here from x, y STEP (draw square) f, f
One may also STEP from the last point in the last drawing command be it circle, pixel, line and do this
rect step xdistance, ydistance
more practically used with line drawing for turtle like or pencil like drawing.
REM step demo.bas 2016-02-16 SmallBASIC 0.12.0 [B+=MGA]
' for STEP to work it needs a place to STEP from:
' PSET, LINE, CIRCLE some graphic x,y pixel location
'PSET is typical start place for turtle like drawings
sx=xmax/50:sy=ymax/50
pset xmax/2,ymax/2 '<==pset is used here to provide STEP a relative place to STEP from
i=0
while i*sx<xmax 'once one x,y pixel reference is set you can STEP out to your hearts desire
i+=1
color 14,14
line step sx*i,0
color 9,9
line step 0,sy*i
i+=1
color 12,12
line step -1*i*sx,0
color 11,11
line step 0,-1*i*sy
wend
pause
-
Thanks a lot B+,
I especially appreciated your exhaustive explanation on the purpose and importance of STEP operator in the FOR/NEXT loops of most BASIC dialects to keep up their consistency with one another. ;D
Anyway, as I see it from your appended explanation STEP in a RECT/PSET/LINE etc. statement is used to denote a relative coordinate step away from wherever it was left at by the preceding drawing operation using these commands, rather than an absolute position at which the current drawing operation is supposed to begin.
Your explanation was really helpful for me to make out what's what in your code. My PSET, LINE (a.k.a. RECTANGLE and PARALLELOGRAM, empty and filled), CIRCLE (a.k.a. ELLIPSE and PIE, empty and filled), and ARC (a.k.a. SEGMENT, empty and filled) also have relative flags for their starting and ending coords, and relative positions can always be polled with CURRENTX and CURRENTY functions. In short, going the VB style, you know...
[UPD] Not to be unfounded: :)
REM Port to FBSL v3.5 2016-09-20 [ML<=B+=MGA]
REM Step demo.bas 2016-02-16 SmallBASIC 0.12.0[B+=MGA]
' for STEP to work it needs a place to STEP from:
' PSET, LINE, CIRCLE some graphic x,y pixel location
'PSET is typical start place for turtle like drawings
#AppType Console
#Option Implicit
#Include "Canvas.inc"
With Canvas
.Window("Relative Coords Demo", 1280, 720)
sx = .Width / 50: sy = .Height / 50
.CurrentX(.Width / 2) '<==pset is used here to provide STEP a relative place to STEP from
.CurrentY(.Height / 2)
i = 0
While i * sx < .Width 'once one x,y pixel reference is set you can STEP out to your hearts desire
.Line(,, sx * Incr(i), 0, &HFFFF,,, TRUE, TRUE)
.Line(,, 0, sy * i, &HFF0000,,, TRUE, TRUE)
.Line(,, -Incr(i) * sx, 0, &HFF,,, TRUE, TRUE)
.Line(,, 0, -i * sy, &HFFFF00,,, TRUE, TRUE)
WEnd
End With
-
JavaScript (using P5.js):
var x, y, s, a, b, c, d, kol, s
function setup() {
createCanvas(800, 600);
background('black');
s = 1000;
}
function mouseClicked() {
if (s == 1000) {
s = 500;
}
else {
s += 5;
}
for (x = 0; x <= 800; x++) {
for (y = 0; y <= 600; y++) {
a = x * s / 600;
b = y * s / 600;
c = a * a + b * b;
d = c / 2;
d = d - Math.floor(d);
if (d < 0.25) {
kol = color(d * 4, 0, 0);
}
else if (d < 0.5) {
kol = color(0, 2 * d, 0);
}
else if (d < 0.75) {
kol = color(0, 0, 4 / 3.0 * d);
}
else {
kol = color(255, 0, 0);
}
stroke(kol);
point(x, y);
}
}
}
Example is attached. You need to click on a black canvas first to start the drawing.
-
well ok work but after 10 seconds browser doing something ::)
-
well ok work but after 10 seconds browser doining something ::)
I don't know what your browser is doing after 10 seconds. Mine is doing nothing (apart from executing that code). You need to talk to it. ;D
-
JavaScript (using P5.js):
var x, y, s, a, b, c, d, kol, s
function setup() {
createCanvas(800, 600);
background('black');
s = 1000;
}
function mouseClicked() {
if (s == 1000) {
s = 500;
}
else {
s += 5;
}
for (x = 0; x <= 800; x++) {
for (y = 0; y <= 600; y++) {
a = x * s / 600;
b = y * s / 600;
c = a * a + b * b;
d = c / 2;
d = d - Math.floor(d);
if (d < 0.25) {
kol = color(d * 4, 0, 0);
}
else if (d < 0.5) {
kol = color(0, 2 * d, 0);
}
else if (d < 0.75) {
kol = color(0, 0, 4 / 3.0 * d);
}
else {
kol = color(255, 0, 0);
}
stroke(kol);
point(x, y);
}
}
}
Example is attached. You need to click on a black canvas first to start the drawing.
Feedback: On my Windows 10 system, code does not respond to any normal exits like clicking the X box in top, right corner.
I don't know why you have this:
if (d < 0.25) {
kol = color(d * 4, 0, 0);
}
else if (d < 0.5) {
kol = color(0, 2 * d, 0);
}
else if (d < 0.75) {
kol = color(0, 0, 4 / 3.0 * d);
when the only coloring done is by this:
else {
kol = color(255, 0, 0);
Try {
kol = color(d * 4 * 255, 0, 0);
}
else if (d < 0.5) {
kol = color(0, 2 * d * 255, 0);
}
else if (d < 0.75) {
kol = color(0, 0, 4 / 3.0 * d * 255);
}
else {
kol = color(255, 255, 255);
the else change is to brighten up a dark screen, some white helps.
Append:
'pattern.bas for SmallBASIC 0.12.7
'2016-09-21 mod for RGB and pixels
s=5
while 1
for i=0 to 800
for j=0 to 600
x=i*s/600
y=j*s/600
c= x*x+y*y
d=c/2
d=d-int(d)
if d <0.25 then
cc=rgb(d*4*255,0,0)
elif d<.5
cc=rgb(0,(4*(d-.25)*255)%255,0)
elif d<.75
cc=rgb(0,0,(4*(d-.5)*255)%255)
else
cc=rgb(255,255,255)
fi
pset i,j,cc
next
next
showpage
pause
s+=5
if s>1000 then s=5
wend
At s = 5 the palette looks like the attached.
-
Feedback: On my Windows 10 system, code does not respond to any normal exits like clicking the X box in top, right corner.
What browser do you use? Firefox complains about busy script sometimes. Chromium works fine. But, I've never tried it on Windows. I replied to Aurel's post that way, because I found his words a bit funny. :)
I don't know why you have this:
I have no idea. I've translated someone else's example from this topic. :)
-
Feedback: On my Windows 10 system, code does not respond to any normal exits like clicking the X box in top, right corner.
What browser do you use? Firefox complains about busy script sometimes. Chromium works fine. But, I've never tried it on Windows. I replied to Aurel's post that way, because I found his words a bit funny. :)
I don't know why you have this:
I have no idea. I've translated someone else's example from this topic. :)
I use FireFox, I can try on Edge.
Yeah, because you are using a translation of my code, I am trying to help you get it right.
I posted another version with RGB color instead RGBF. (above) S = 5, the very first screen, is like a perfect palette display for things to come.
I am pretty sure even if you are color blind you will like the difference because the shadings are missing.
-
...so you don't believe...nice but is true.
i open your html file in Opera on win7 then what i see is just black rectangle
which not respond aftter i click on ..that take cca 10 sec then i see drawing :o
KMeleone need cca 30 seconds to show drawing
-
Yeah, I have tested it now on Edge, MS browser, and like on FireFox it is runs slow as the dickens.
Again when I try to exit by clicking the top right X box to close, there is no immediate response. There is no indication that my click has been received... I end having to find alternative ways to close the thing.
-
Python (using graphics.py):
from graphics import *
xmax = 800
ymax = 600
win = GraphWin('Circles', xmax, ymax)
win.autoflush = False
win.getMouse()
while 1:
s = 500
for x in range(0, xmax + 1):
for y in range(0, ymax + 1):
a = x * s / 600.0
b = y * s / 600.0
c = a * a + b * b
d = c / 2.0
d = d - int(d)
if d < 0.25:
kol = color_rgb(d * 4, 0, 0)
elif d < 0.5:
kol = color_rgb(0, 2 * d, 0)
elif d < 0.75:
kol = color_rgb(0, 0, 4 / 3.0 * d)
else:
kol = color_rgb(255, 0, 0)
win.plot(x, y, kol)
print x
win.flush()
win.getMouse()
if s == 1000:
s = 500
else:
s += 5
OK finally got this working running from Geany and putting import file in same folder.
New color scheme now has full RGB range and some white to brighten screens. For longest time I couldn't figure why screen was getting stuck after first loop. It was because s being reset back to start right after while 1:
These screens take 4-5 minutes to do 800x600 pixels about same speed as JB pixel drawing:
from graphics import *
xmax = 800
ymax = 600
win = GraphWin('Circles', xmax, ymax)
win.autoflush = False
s = 35
loop = 1
while 1:
for x in range(0, xmax + 1):
for y in range(0, ymax + 1):
a = x * s / 600.0
b = y * s / 600.0
c = a * a + b * b
d = c / 2.0
d = d - int(d)
d = int(d * 1000)
if d < 250:
kol = color_rgb(d, 0, 0)
elif d < 500:
kol = color_rgb(0, d - 250, 0)
elif d < 750:
kol = color_rgb(0, 0, d - 500)
else:
kol = color_rgb(255, 255, 255)
win.plot(x, y, kol)
if loop == 1:
win.flush()
if loop > 1:
win.flush()
loop += 1
if s == 1000:
s = 5
else:
s += 5
print(s)
-
Feedback: On my Windows 10 system, code does not respond to any normal exits like clicking the X box in top, right corner.
Yeah, I have tested it now on Edge, MS browser, and like on FireFox it is runs slow as the dickens.Again when I try to exit by clicking the top right X box to close, there is no immediate response. There is no indication that my click has been received... I end having to find alternative ways to close the thing.
The only sure way to have it running at any reasonable speed would be to change one statement in the function setup() and two statements in the function mouseClicked() in the sketch.js file that you downloaded, to the following:
........
createCanvas(320, 200);
........
for (x = 0; x <= 320; x++) {
for (y = 0; y <= 200; y++) {
........
JavaScript is terribly slow drawing anything in a bigger canvas. And for each new pattern you have to click again as there's no outer loop that would've made your browser entirely unresponsive with the 800x600 px canvas. And I suspect Tomaaz knew this when uploading the sample... ;)
-
Thanks Mike,
Much more responsive! Check this out:
var x, y, s, a, b, c, d, kol, s
function setup() {
createCanvas(320, 200);
background('black');
s = 1000;
}
function mouseClicked() {
if (s == 1000) {
s = 5;
}
else {
s += 5;
}
for (x = 0; x <= 320; x++) {
for (y = 0; y <= 200; y++) {
a = x * s / 600;
b = y * s / 600;
c = a * a + b * b;
d = c / 2;
d = d - Math.floor(d);
d = d * 1000;
if (d < 250) {
kol = color(d, 0, 0);
}
else if (d < 500) {
kol = color(0, d - 250, 0);
}
else if (d < 750) {
kol = color(0, 0, d - 500);
}
else {
kol = color(255, 255, 255);
}
stroke(kol);
point(x, y);
}
}
}
EDIT: missed a ; after d = d * 1000
-
Sorry, been muted by the net failure.
Works great but the patterns are different from GDI because JS uses browser canvases that are WebGL driven and in fact use anti-aliasing and subpixel metrics.
Updated my code with your mods. Using 2x2 filled boxes:
-
JavaScript is terribly slow drawing anything in a bigger canvas. And for each new pattern you have to click again as there's no outer loop that would've made your browser entirely unresponsive with the 800x600 px canvas. And I suspect Tomaaz knew this when uploading the sample... ;)
This example is not coded in pure JavaScript. It uses P5.js which is Processing for JavaScript. I'll write and post a pure JavaScript version when I'm free.
-
we will wait ...
After you finish the job in the toilet, you're free
and then smash that java scripts ass >:(
-
JavaScript is terribly slow drawing anything in a bigger canvas...
Terribly slow, you say? :) Try this. This is a pure low-level JavaScript version. You don't need to click anything. It updates by itself about... 10 times per second on my machine (of course it depends on a browser you use). I wouldn't call it terrible slow. It is rather fast. ;)
<!DOCTYPE html>
<html>
<head>
<title>Mandelbrot</title>
<script>
var s = 1000;
function aktywuj() {
plotno = document.getElementById("rysunek");
zawartosc = plotno.getContext("2d");
zawartosc.fillStyle = "#000000";
zawartosc.fillRect(0,0,800,600);
t = setTimeout("rysuj()", 1);
}
function rysuj() {
var canvas = document.getElementById('rysunek');
var ctx = canvas.getContext('2d');
var canvasData = ctx.createImageData(canvas.width, canvas.height);
for (var x = 0; x < 800; x++) {
for (var y = 0; y < 600; y++) {
var idx = (x + y * 800) * 4;
a = x * s / 600;
b = y * s / 600;
c = a * a + b * b;
d = c / 2;
d = d - Math.floor(d);
d = d * 1000;
if (d < 250) {
r = d;
g = 0;
b = 0;
}
else if (d < 500) {
r = 0;
g = d - 255;
b = 0;
}
else if (d < 750) {
r = 0;
g = 0;
b = d - 500;
}
else {
r = 255;
g = 255;
b = 255;
}
canvasData.data[idx + 0] = r;
canvasData.data[idx + 1] = g;
canvasData.data[idx + 2] = b;
canvasData.data[idx + 3] = 255;
}
}
if (s == 1000) {
s = 500;
}
else {
s += 5;
}
var k = ctx.putImageData(canvasData, 0, 0);
t = setTimeout("rysuj()", 1);
}
</script>
</head>
<body onload = "aktywuj()">
<div>
<canvas id="rysunek" width="800" height="600"></canvas>
</div>
</body>
</html>
The file is attached. It's a single HTML file. Just open it in your browser.
EDIT 10 times per second in Microsoft's browsers. In Firefox it runs much faster. To be honest, I wasn't expecting it to be that fast. :)
-
ok.,.
in Opera work fine and not very fast..
in Firefox not ,also in Kmeleon not , in SlimBoat(Qt) work
-
WOW Tomaaz, that is mind blowing !!!
I am a believer now. Whew!
I recommend a little change to make it clear when you've cycled through about 200 screens in less time than it takes to create one half of one in Python, and probably less than half the time my fastest, Naalaa, can cycle through the range of s:
if (s == 1000) {
s = 5;
}
Starting at s = 5 and for a half dozen screens, s = 5, 10, 15, 20, 25,... you can get a taste of how the Connett Circles progress.
-
Terribly slow, you say? :)
"Terribly" slow in conjunction with that py library you suggested. :)
It updates by itself about... 10 times per second on my machine (of course it depends on a browser you use).
On my machine, it actually runs at ~55 FPS (http://www.fraps.com/download.php) in both FF and Opera. That's remarkable, thanks Tomaaz!
-
That is fast. By comparison, my specbas code snippet above takes 120ms to draw one frame whereas this seems to be getting in about 15 fps, almost twice as fast.
-
:) Here is Connett Circles, "The Movie", code changes to Tomaaz html:
var s = 1000.0;
if (s == 1000.0) {
s = 1.0;
}
else {
s += 0.1;
}
-
:) Here is Connett Circles, "The Movie"...
Wow! That looks psychodelic. ;)
-
I was so impressed by the speed of manipulating image data directly that I decided to rewrite my Mandelbrot animation using this approach. And, again, the result is mind-blowing! It's faster than FreeBASIC. :o
<!DOCTYPE html>
<html>
<head>
<title>Mandelbrot Set</title>
<meta charset="utf-8">
<style type="text/css">
body {background-color: black}
div {text-align: center}
</style>
<script>
przelx = 3 / 240;
przely = 2 / 160;
powiekszenie = 1;
przesx = 14.17799995;
przesy = 79.999904;
function rysuj() {
canvas = document.getElementById("rysunek");
ctx = canvas.getContext("2d");
ctx.fillStyle = "#000000";
ctx.fillRect(0,0,240,160);
var canvasData = ctx.createImageData(canvas.width, canvas.height);
przelx = 3 / (240 * powiekszenie);
przely = 2 / (160 * powiekszenie);
for (x = 0; x < 240; x++) {
x3 = x - 120;
for (y = 0; y < 160; y++) {
var idx = (x + y * 240) * 4;
y3 = y - 80;
c = 0;
a = 0;
b = 0;
z = 0;
x2 = (przelx * (x3 + (przesx * powiekszenie))) - 2;
y2 = (przely * (y3 + (przesy * powiekszenie))) - 1;
while (c < 255 && z < 4) {
a2 = a * a - b * b;
b2 = 2 * a * b;
a = a2 + x2;
b = b2 + y2;
z = a * a + b * b;
c = c + 1;
}
if (c == 255) {
c = 0;
k = 0;
l = 0;
}
else {
k = (c % 50) * 5;
l = 255 - c;
}
canvasData.data[idx + 0] = c;
canvasData.data[idx + 1] = k;
canvasData.data[idx + 2] = l;
canvasData.data[idx + 3] = 255;
}
}
var kupa = ctx.putImageData(canvasData, 0, 0);
if (powiekszenie < 1562550000000) {
powiekszenie = powiekszenie + powiekszenie * 0.1;
var t = setTimeout("rysuj()", 0);
}
}
</script>
</head>
<body onload = "rysuj()">
<div>
<canvas id="rysunek" width="240" height="160"></canvas>
<form name="czas">
<input type = "text" id = "pole" style="background-color: black; color: white; border: none">
</form>
</div>
</body>
</html>
This runs at the full speed, some parts are faster than others (due to a different amount of calculations that need to be used to render different part of the fractal). If you want to do it a bit slower and smoother just increase the number in this line: var t = setTimeout("rysuj()", 0). Zero means that the function will be called again instantly. If you specify the number it will be the number of milliseconds the function will be called again after the program returns from the previous call. Again, it runs much faster in Firefox than in Microsoft's browsers.
-
the result is mind-blowing! It's faster than FreeBASIC. :o
For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though. Try the attachment...
arrow left/right/up/down moves the image
+ key starts zooming in
- key starts zooming out
mousewheel works, too
-
the result is mind-blowing!
More motivation to get the Script BASIC JavaScript extension module completed.
Thanks Tomaaz for sharing your JavaScript expertise.
-
For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though.
Speed depend's a lot on number of iterations and colour depth? Well, it's not exactly like that. In this case both speed and colour depth depend entirely on number of iterations (max. 255 in this example). ;) On my computer, FreeBASIC version that uses the same size, depth and algorithm is slower than this code run in Firefox. I've written Mandelbrot viewer in all languages I've ever tried and untill now FreeBASIC version was the fastes one. Until now. ;)
EDIT It runs significantly slower in IE, Edge and Chromium.
-
I was so impressed by the speed of manipulating image data directly that I decided to rewrite my Mandelbrot animation using this approach. And, again, the result is mind-blowing! It's faster than FreeBASIC. :o
So I made a version in BaCon, added a timer to your Java Script code, and to my code as well.
Result is that the Java Script version using Firefox runs in 4950 msecs average, and the BaCon version compiled with -O3 optimization runs in 5660 msecs average. Pretty cool that Java Script!
INCLUDE canvas.bac
'INCLUDE canvas-gd.bac
OPTION VARTYPE FLOATING
WINDOW("Mandelbrot Set", 240, 160)
przelx = 3 / 240
przely = 2 / 160
magnification = 1
przesx = 14.17799995
przesy = 79.999904
SUB rysuj
przelx = 3 / (240 * magnification)
przely = 2 / (160 * magnification)
FOR x = 0 TO 240
x3 = x - 120
FOR y = 0 TO 160
y3 = y - 80
c = 0
a = 0
b = 0
z = 0
x2 = (przelx * (x3 + (przesx * magnification))) - 2
y2 = (przely * (y3 + (przesy * magnification))) - 1
WHILE c < 255 AND z < 4
a2 = a * a - b * b
b2 = 2 * a * b
a = a2 + x2
b = b2 + y2
z = a * a + b * b
c = c + 1
WEND
IF c = 255 THEN
c = 0
k = 0
l = 0
ELSE
k = MOD(c, 50) * 5
l = 255 - c
ENDIF
INK(c, k, l, 255)
PIXEL(x, y)
NEXT
NEXT
IF magnification < 1562550000000 THEN
magnification = magnification + magnification * 0.1
ELSE
PRINT "Done in ", TIMER, " msecs."
END
ENDIF
END SUB
'FRAMES(300)
CALLBACK(1, rysuj)
WAITKEY
Unfortunately, browsers do not render GIF images in a correct speed. The fastest Firefox can do is 0.1 second. If you download the GIF below and present it in a picture viewer, the animation will be a lot faster.
(http://www.basic-converter.org/canvas/Mandelbrot.gif)
-
Result is that the Java Script version using Firefox runs in 4950 msecs average, and the BaCon version compiled with -O3 optimization runs in 5660 msecs average. Pretty cool that Java Script!
Yep. I still can't believe how fast it is. :) I'm also really surprised it is Firefox that beats other browsers (I would bet on Chromium/Chrome if someone asked me).
-
And, again, the result is mind-blowing! It's faster than FreeBASIC. :o
.........
Again, it runs much faster in Firefox than in Microsoft's browsers.
Pretty cool that Java Script!
Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.
Long live AOT and JIT compilation! :D
Literature:
1) Why is JS so fast in Firefox? (http://www.theregister.co.uk/2013/12/20/native_code_no_its_javascript_only_its_blazing_fast/)
2) Asm.js (http://asmjs.org/spec/latest/).
-
Thanks Mike for the info!
I'm installing Emscripten which is a tool to convert C/C++ code to LLVM bytecode and then to asm.js JavaScript code. Emscripten can also generate HTML for testing embedded JavaScript.
(https://dab1nmslvvntp.cloudfront.net/wp-content/uploads/2014/05/1400116298cpptojs.png)
I'll post something if it turns out to be interesting.
Mandlebrot Interactive (http://jblang.github.io/XaoSjs/index.html)
Update
Generates a huge amount of JavaScript code for simple hello_world.c.
-
Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.
So? :) It's still pretty impressive. I don't really understand your problem. They implemented support for asm.js in their JavaScript engine. Good for them. And for JavaScript. :)
Literature:
1) Why is JS so fast in Firefox? (http://www.theregister.co.uk/2013/12/20/native_code_no_its_javascript_only_its_blazing_fast/)
2) Asm.js (http://asmjs.org/spec/latest/).
Well, yes. But in 99% cases I've found Firefox to be slower. Even this animation written with Canvas methods will run faster in Chrome. That's why I'm surprised by the speed of Firefox in this case. Mike, you focus to much on theory. :) I don't really care if it is asm.js, native code... whatever. I have a piece of JavaScript code and, in Firefox, it runs faster tha FreeBASIC example and that's what matters to me.
-
I don't really understand your problem.
My problem? I've no problems, Tomaaz. My FBSL's been using JIT compilation for years, if not decades. :) That's more of a problem of language implementations that don't and won't use it OOTB so that 3rd parties have no other choice but to galvanize them forcibly each in their own unique way. (cf. R.Russell and his LBB Galvanizer)
Mike, you focus to much on theory. :)
No Tomaaz. I'm a man of action. Almost all my ideas get implemented immediately on formulation. :)
I don't really care if it is asm.js, native code... whatever.
I think you should, from time to time. For all intents and purposes, JJ's Mandel runs at least as fast if not faster, especially in a compatible much smaller window, than that FF trickery that's been disguised in that JS outfit to fool inexperienced users into thinking bytecode can compete with static or dynamic compilation to machine code. I'm even leaving out the discussion of FF's hardware-accelerated OpenGL canvases (in fact, entire pages) that also contribute much to FF being the leader in browser rendering despite its huge size. :)
This isn't theory, Tomaaz. That's straight-forward practice based on knowledge and reason.
-
For a browser, it's indeed very fast. Speed depends a lot on colour depth and the number of iterations, though.
Speed depend's a lot on number of iterations and colour depth? Well, it's not exactly like that. In this case both speed and colour depth depend entirely on number of iterations (max. 255 in this example). ;)
Yes, my statement was a bit sloppy. More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)
-
My problem? I've no problems, Tomaaz.
Well, it seems that you have. Problem either with JavaScript itself or me and Peter being impressed by Firefox running that code. That's how the whole argument started. ;)
No Tomaaz. I'm a man of action. Almost all my ideas get implemented immediately on formulation. :)
OK. You're man of action, sometimes focused to much on theory (especially when discussing someone else's impressive achievements). ;)
I think you should, from time to time. For all intents and purposes, JJ's Mandel runs at least as fast if not faster, especially in a compatible much smaller window, than that FF trickery that's been disguised in that JS outfit to fool inexperienced users into thinking bytecode can compete with static or dynamic compilation to machine code. I'm even leaving out the discussion of FF's hardware-accelerated OpenGL canvases (in fact, entire pages) that also contribute much to FF being the leader in browser rendering despite its huge size. :)
And you say that you have no problems. ;D No one is trying to fool anyone. No one is hiding any facts. And what's wrong with using all available options to improve a web browser performance??? Once again - I can't understand your problem. ;D
This isn't theory, Tomaaz. That's straight-forward practice based on knowledge and reason.
That is a theory and a very strange one. ;D
Yes, my statement was a bit sloppy. More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)
Is your example written in FreeBASIC? Because all I said it was that on my computer, FreeBASIC version that uses the same size and algorithm is slower. Did I say this is the fastest Mandelbrot possible? No, so what's your problem guys? It was just a simple example that wasn't meant to prove anything general. Calm down. ;)
-
Cool down, guys. What you're seeing in Firefox is not JavaScript's merit. It is the result of ahead-of-time (AOT) compilation of a subset of JS vocabulary to native assembly done transparently in FF by its dev wizards.
Long live AOT and JIT compilation! :D
Thanks for letting know Mike. I wonder if the concept of Ahead Of Time compilation (https://en.wikipedia.org/wiki/Ahead-of-time_compilation) also can work for C. I have tried some other GCC optimization options and this brought down the performance even further (from 5660 msecs average back to 5370 msecs average). Maybe with the right options I can achieve the right performance :)
Best regards
Peter
EDIT: the following system dependent GCC options (https://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Optimize-Options.html) brought the performance back to 5120 average, getting closer to Java Script AOT compilation: -O3 -fomit-frame-pointer -march=native -flto -mfpmath=both -funroll-loops -ffast-math
-
My FBSL's been using JIT compilation for years, if not decades.
I feel every BASIC author, project manager and contributor is proud of their accomplishments. Some share the user experience while others share the source. I think it's healthy to have challenges on the forum as it gives us a chance to see different perspectives.
-
Problem either with JavaScript itself or me and Peter ...
And you say that you have no problems. ... Once again - I can't understand your problem.
No, so what's your problem guys?
Tomaaz, who's having obvious problems if not you -- alone? :D
In fact, we all liked your code snippet and the effect that it produced in a very special browser -- the Firefox. We just wanted to point out that it wasn't JavaScript's merit (https://translate.google.by/?hl=ru&tab=wT#en/pl/merit) (let it draw on a GDI canvas and see what it's worth), but rather the merit of people who were able to turn it on the fly into highly efficient assembly/machine code coupled with a WebGL canvas. That's exactly what we're discussing with JJ and Peter, just in case you haven't yet guessed for yourself.
-
I have been playing with the Emscripten C/C++ to JavaScript translator with a asm.js twist and have come to the conclusion that it generates way too much code to be usable. (for me) The silver lining is that it does generate advanced JavaScript functions and routines I can cheery pick and may use in my projects.
-
Peter,
Judging by the looks of it, -fomit-frame-pointer and -ffast-math should be the ones that did the trick, especially if you formulated your drawing routine as a subprocedure. The other ones seem to be enabled in any -On except for -Os on default. My (almost) unoptimizing DynC yields (almost) twice slower speed in my GDI canvas on my PC that's also objectively slower than yours by perhaps some 20 or 25%.
[UPD] I've taken that last step and got rid of direct Canvas drawing functions altogether. Now all Canvas methods simply modify the contents of pixel array that's assigned to the Canvas DIB (device independent bitmap) once per Refresh() call. That's roughly what Tomaaz' canvasData.data[] does. Also, I chose the variable data types more carefully to avoid unnecessary casts. Got me almost 40% extra speed even though I can't enjoy the benefits of -O3 & Co. :) (yet something's telling me JJ can still do it at half the time and twice the speed tho... ;) )
Can I ask you to run the attached executable in your Wine, if at all possible? I'd like to get an idea of speed differences between our HW.
#AppType Console
#Include "Canvas.inc"
With Canvas
.Window("Mandelbrot Zoom", 240, 160) // (c)Tomaaz 09/27/2016
While .hWnd And Also Rysuj(.Pixels)
.Refresh()
WEnd
End With
DynC Rysuj(%pxs)
#define RGB(r, g, b) (r) << 16 | (g) << 8 | (b)
int main(int* pxs)
{
static double powiekszenie = 1.0, przesx = 14.17799995, przesy = 79.999904;
double a, a2, b, b2, x2, x3, y2, y3;
int x, y, z, idx;
unsigned char c, k, l;
double przelx = 3 / (240 * powiekszenie);
double przely = 2 / (160 * powiekszenie);
for (x = 0; x < 240; x++) {
x3 = x - 120;
for (y = 0; y < 160; y++) {
idx = x + y * 240;
y3 = y - 80;
c = a = b = z = 0;
x2 = przelx * (x3 + przesx * powiekszenie) - 2;
y2 = przely * (y3 + przesy * powiekszenie) - 1;
while (c < 255 && z < 4) {
a2 = a * a - b * b;
b2 = 2 * a * b;
a = a2 + x2;
b = b2 + y2;
z = a * a + b * b;
c++;
}
if (c == 255)
c = k = l = 0;
else {
k = (c % 50) * 5;
l = 255 - c;
}
pxs[idx] = RGB(c, k, l);
}
}
if (powiekszenie < 1562550000000) {
powiekszenie += powiekszenie * 0.1;
return 1;
}
return 0;
}
End DynC
-
John,
Frankly I don't see much point in C++/C-to-JS translation. I can hardly imagine myself allowing some third party proggy to translate my DynC or DynAsm routines to LB/LBB. It should be the other way round to make any sense at all. :)
-
It should be the other way round to make any sense at all.
The closes I've come is making C look like BASIC is with my C BASIC effort. (now a Script BASIC extension module standard)
-
Problem either with JavaScript itself or me and Peter ...
And you say that you have no problems. ... Once again - I can't understand your problem.
No, so what's your problem guys?
Tomaaz, who's having obvious problems if not you -- alone? :D
In fact, we all liked your code snippet and the effect that it produced in a very special browser -- the Firefox. We just wanted to point out that it wasn't JavaScript's merit (https://translate.google.by/?hl=ru&tab=wT#en/pl/merit) (let it draw on a GDI canvas and see what it's worth), but rather the merit of people who were able to turn it on the fly into highly efficient assembly/machine code coupled with a WebGL canvas. That's exactly what we're discussing with JJ and Peter, just in case you haven't yet guessed for yourself.
1. When rendering Mandelbrot, calculations take majority of time and power, not drawing.
2. This example doesn't use WebGL.
3. You can disable hardware acceleration and it will be working with the same speed.
And of course, it works that fast only in Firefox. I pointed it out several times, so could you please stop acting like I didn't? Unlike other languages (Perl, Python, Ruby, Lua...) JavaScript doesn't have a standard/official interpreter. Yes, you can say that Luajit is faster than standard Lua or that PyPy is faster than official Python interpreter, but the same doesn't apply to JavaScript. So, Firefox "is cheating, trying to fool inexperienced users" as opposed to what? Also, what do you mean by "JavaScrip's merits" in terms of performance? As I said, it doesn't have an official distribution, so it's is as good, as its the best implementation.
Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set (https://en.wikipedia.org/wiki/Mandelbrot_set)
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL (https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)
-
Can I ask you to run the attached executable in your Wine, if at all possible? I'd like to get an idea of speed differences between our HW.
No problem, your program runs fine in Wine 1.6.2, and even then the performance is slightly better than my GL canvas (see screenshot) :)
On my system I noticed that the -flto flag (Link Time Optimization) also made a big difference.
Regards
Peter
-
No problem, your program runs fine in Wine 1.6.2
You're very nice Peter, thanks a lot!
... and even then the performance is slightly better than my GL canvas (see screenshot) :)
That's very flattering too! :D
Seriously, I don't know how exactly your PIXEL() call is implemented but at least under Windows (probably your Mesa is also capable of doing that) OpenGL would allow us to manipulate Canvas texel data via glTexSubImage2D() and its associated buffers, i.e. to perform the exact same trick of canvasData.data[idx]=/ctx.putImageData(canvasData) used by Tomaaz in his JS and pxs[idx]=/SetDIBitsToDevice(pxs) used by me in my C code. On a 240x160 px canvas, it would spare you some 38,400 (presumably) primitive function calls fast as they may be in a HW assisted OpenGL implementation.
On my system I noticed that the -flto flag (Link Time Optimization) also made a big difference.
I can't comment exhaustively on that one because the early TDM GCC 4.3.3 I'm still using for FBSL compilation doesn't perform such an optimization yet. From what I know theoretically LTO uses some form of internal IL (intermediate language) to allow for inter-module inlining of functions. GCC 4.3.3 can only inline functions within the scope of .o module they are defined in while later GCC versions can also do it at the application global level. Probably something in your language implementation can benefit substantially from that particular optimization too. :)
-
Tomaaz,
You don't have to lecture me on fractal rendering. I've been drawing all sorts of GDI/OpenGL/GLSL Mandel/Julia/Buddha/brots/boxes in multiple dimensions
in FBSL:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/JuliaRings.png)
(http://www.fbsl.net/phpbb2/download/file.php?id=1816)
in thinBasic:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/Interference.png)
(http://www.fbsl.net/phpbb2/download/file.php?id=1819)
in OxygenBasic and other languages suitable for the purpose:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/DuoMandel.png)
1. When rendering Mandelbrot, calculations take majority of time and power, not drawing.
Nope. In 256 iterations per pixel, the pixel draw call will take probably 70% of the time. In 1024 iterations, as ZXDunny once claimed, it's probably gonna be a 50/50 deal, but if you subside to a couple dozen iterations and integer maths, you'll get a blazing fast Mandelbrot whose speed will only be limited to how fast your PRINT works:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/MandelKen.png)
2. This example doesn't use WebGL.
Let me decide what does and what doesn't, OK Tomaaz? I'm perfectly suited for the task of determining the underlying technologies by the looks of them. I've got enough personal experience for that, from assembly up to GLSL, if you haven't yet noticed it:
(http://i1240.photobucket.com/albums/gg490/FbslGeek/MacOSXLion-FBSLv35.png)
3. You can disable hardware acceleration and it will be working with the same speed.
That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation. There's nothing to accelerate any further, Tomaaz. The devs had already done everything for you before you even formulated the task. :)
And of course, it works that fast only in Firefox.
Nope. It works exactly as fast in my FBSL GDI canvas as well as in Peter's BaCon OpenGL/Mesa canvas. And I'm stressing again, Jochen's hand written assembly may easily beat the whole bunch of us probably by a factor of two, should he so wish.
Also, what do you mean by "JavaScrip's merits" in terms of performance? As I said, it doesn't have an official distribution, so it's is as good, as its the best implementation.
Exactly. JS isn't a language implementation, it's only a definition of a specific set of grammar rules to be followed adding web interop to your applications. Just like OpenGL isn't a specific .dll or .lib file but rather a specification of the user-side functionality of a unified set of HW assisted APIs to be built into the low level drivers that graphics accelerator vendors supply their GPUs with.
Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set (https://en.wikipedia.org/wiki/Mandelbrot_set)
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL (https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)
Hmm, what should I do with this one? I guess I'd rather leave it here just in case someone might find it useful, just like you did. :)
-
That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation.
Exactly! That's why this example represents pure JavaScript speed. It would be even better if we reduced interacting with DOM to an absolute minimum or even removed it completely (but, of course, it's nice to see the result on the screen, isn't it? ;)).
There's nothing to accelerate any further, Tomaaz. The devs had already done everything for you before you even formulated the task. :)
Yes. The devs of the JavaScript engine did a great job, indeed. Thanks to them I can enjoy JavaScript scripts that runs faster than FreeBASIC compiled code. I'm pretty happy about it. Do you finally get what I mean? I know JavaScript. I can write a script in it. I can run it in Firefox and it runs faster than FreeBASIC programs. I like the situation very much and I salute people who made it possible. If they decided to employ Lord Vader and use The Force to make their engine faster, that's absolutely fine for me. :) Simply as that.
And of course, it works that fast only in Firefox.
Nope. It works exactly as fast in my FBSL GDI canvas as well as in Peter's BaCon OpenGL/Mesa canvas. And I'm stressing again, Jochen's hand written assembly may easily beat the whole bunch of us probably by a factor of two, should he so wish.
This part shows either that you really can't understand what I'm saying or that you just trying to manipulate my words to prove your point. Because, well... it wasn't very difficult to figure it out that I was talking about my JavaScript code and the fact that it runs that fast in Firefox only and the animation is significantly slower when run in Chromium, IE and Edge. I've never said that this is the fastest Mandelbrot animation possible or that code written in Assembly or C (or anything) wouldn't be able to beat it. All I said it was that I was impressed by what I saw on the screen (Peter kind of agreed with me, so why do you keep bringing his name here?) and that it was faster than the same algorithm compiled with FreeBASIC. The rest is all your imagination. :)
Literature:
https://en.wikipedia.org/wiki/Mandelbrot_set (https://en.wikipedia.org/wiki/Mandelbrot_set)
https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL (https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/Tutorial/Getting_started_with_WebGL)
Hmm, what should I do with this one?
Read it? ;D
Let me decide what does and what doesn't, OK Tomaaz?
That explains it all. It's pointless to argue with a God. There is no chance to win, so let's end this farse, here. ;D
More correctly, my Mandelbrot implementation does one Million iterations in about 11 milliseconds on a Core i5. If you resize the window to match the browser example, you might see the difference. Or better, change the browser example so that it shows a full screen ;-)
900x600 example in JavaScript takes on my computer (in Firefox) 120ms to render (almost 6 million iterations). Your example takes 80ms for about the same number of iterations. You win, but don't tell me that Firefox's result isn't impressive. Well, if you worship that God I had discussion with, I will understand that you must obey your master and cannot agree with me. ;D
-
900x600 example in JavaScript takes on my computer (in Firefox) 120ms to render (almost 6 million iterations). Your example takes 80ms for about the same number of iterations. You win, but don't tell me that Firefox's result isn't impressive.
That is indeed impressive. I think the Mozilla guys try to distract from their other sins (https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/) 8)
Well, if you worship that God I had discussion with, I will understand that you must obey your master
Reminds me of an old joke about a guy whose 80th birthday is today: "What's the difference between God and Berlusconi?" - "God doesn't believe he's Berlusconi..." ;-)
-
That's because you (and I, for that matter) aren't actually drawing anything. We're simply preparing the pixel data array to be drawn on screen refresh in one single swoop rather than in 38,400 distinct draw calls as in a naive BASIC-style implementation.
You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?
I mean, SpecBAS doesn't make use of any Dynarec or JIT whatsoever so can't compete with the speed you guys can achieve and I have to test each pixel plotted by the user for out-of-bounds and such - and a bunch of other things given that you can apply coordinate scaling, clipping and pixel effects - but even so, directly writing pixels out seems like it's an obvious thing to avoid :)
-
That is indeed impressive. I think the Mozilla guys try to distract from their other sins (https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/) 8)
Thank you! ;) And yes - Firefox is not perfect. I use it on Windows and Android, but just took a break from it on Linux. It freezes, crashes and becomes very unresponsive. My main browser on Linux is, at the moment, Chromium.
You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?
Do you mean "host system's"? It sounds a bit confusing to me, but I may be wrong, of course. ;)
-
I think the Mozilla guys try to distract from their other sins (https://www.servethehome.com/firefox-is-eating-your-ssd-here-is-how-to-fix-it/) 8)
If you had the nerve to read the article to the bottom, you surely noticed Update #1 that accuses Chrome of the exact same sin done on twice as large a scope -- 24GB of trash data written to your disk every passing day. I wiped off that piece of bloatware way back when I noticed it wouldn't allow the user to switch off those annoying automatic updates I was seeing three or four times a day 24/7/365, and I never regretted what I did.
You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really? ... directly writing pixels out seems like it's an obvious thing to avoid :)
Why not? Take Ruben for instance... or TOY... ;) The late Bob Zale was correct saying people may use PowerBASIC to develop other languages (re: thinBasic) but they expressly may not just wrap PB's own design solutions to achieve the same functionality in their derivations.
OTOH there's nothing wrong with using ready-made SetPixelV, MoveTo, LineTo, Rectangle, BitBlt, StretchBlt and other Windows system APIs from time to time to resolve immediate tasks -- they've been especially provided for that purpose by the OS developers -- for as long as you aren't attempting to populate a 900x600 px large canvas with psets alone.
It's pointless to argue with a God. There is no chance to win, so let's end this farse, here.
Absolutely. And if there's anyone who's got to be the first to put an end to the flood you stirred up around my simple phrase "is not JavaScript's merit", so let it be me. See you next time around, Tomaaz. :)
-
You mean there's BASICs out there that actually write pixels out using pset (or their host language's equivalent)? Really?
Do you mean "host system's"? It sounds a bit confusing to me, but I may be wrong, of course. ;)
Well, no - there's not many interpreters out there that run on bare metal and most are written in C or somesuch language which usually provide (or have access through a third party library) graphical primitives like pset, line etc. As mike says, they're all well and good for the occasional UI element or whatever, but are hardly suited to shoving large amounts of image pixels around.