Oxygen Basic
Programming => Example Code => Topic started by: Mike Lobanovsky on August 14, 2014, 07:08:19 PM
-
No gents,
I simply can't leave it at that. I'm going to raise Peter's blood pressure one more time being after his scalp again.
In response to my suggestion here (http://www.oxygenbasic.org/forum/index.php?topic=1155.msg10239#msg10239), Peter went on insisting that "The source code looks clean!" (http://www.oxygenbasic.org/forum/index.php?topic=1155.msg10252#msg10252)
No Peter, it is not clean at all. It is just a classic specimen of bloody bloatware copied bluntly from somebody else's code not giving a damn what you were doing.
Change your While block in your scripts as follows:while keydown(27)=0
for y=0 to 240
for x=0 to 320
c1 = sin(x / 50 + f + y / 200)
c2 = sqr((sin(0.8 * f) * 160-x+160) * (sin(0.8 * f) * 160-x+160) + (cos(1.2 * f) * 100-y+100) * (cos(1.2 * f) * 100-y+100))
c2 = sin(c2 / 50)
c3 = (c1 + c2) / 2
res = ((c3 + 1) * 127)
color r[res], g[res], b[res]
setpixel x, y
next
next
f = f+0.2
redraw
windowtitle = "FPS = " & getfps
wendto be able to count your FPS and get your readings as you're recalculating your sines and cosines again and again for nothing.
Now add two more vars to your declaration as follows:single c1,c2,c3,f,sn,csand change your While block as follows:while keydown(27)=0
for y=0 to 240
for x=0 to 320
sn = sin(.8 * f) * 160 - x + 160
cs = cos(1.2 * f) * 100 - y + 100
c1 = sin(x / 50 + f + y / 200)
c2 = sin(sqrt(sn * sn + cs * cs) / 50)
c3 = (c1 + c2) / 2
res = ((c3 + 1) * 127)
color r[res], g[res], b[res]
setpixel x, y
next
next
f = f+0.2
redraw
windowtitle = "FPS = " & getfps
wendand watch your new FPS rate.
On my PC, I am getting a stable increase of 4FPS against the former 20FPS. This is exactly 20% faster than your (OK let's call it "their") bloat!
And you're calling it clean? Well, I wouldn't.
.
-
No Peter, it is not clean at all. It is just a classic specimen of bloody bloatware copied bluntly from somebody else's code not giving a damn what you were doing.
Thanks Mike!
Mystery solved.
-
Well, it looks that work fine ;)
Even in my extremly powerful interpreter ;D
which use some special efects to produce plasma...
/ps yeah..yeah...i am to lazy ....shame on me :-[ /
.
-
Hi Aurel,
Hehe looks original BTW... :)
Yes, it's gonna work faster in every interpreter they promote at their retro-BASIC dot org. But none of them dared to look at where this code came from: the original (https://gist.github.com/stevenlr/824019) was in fact written for SDL in the C language. But every optimizing C compiler would do such code rearrangement transparently without the coder's effort while as I said earlier (http://www.oxygenbasic.org/forum/index.php?topic=1155.msg10239#msg10239), none of our BASIC's is capable of doing it all by itself.
This is why we should use our heads more often and stop peeping each other's bloat over the shoulder.
-
Hi Mike
I see now ..original surface is 320x200 in SDL example
but yes this is C SDL example... ::)
-
I see now ..original surface is 320x200 in SDL example
This size should be small enough for the two nested For/Next loops to run fast enough with all this FPU calc. Peter's DLL does the rest by StretchBlt-ing this small area from a memory DC onto his window DC of any size. But blitting isn't perfect either: i) his window flashes on resizing and dragging, and ii) his blitting into a window smaller than the original 320x240 px is broken with ugly contours.
Properly written pure O2 code would run twice faster than his asm.dll and would not either flicker on resize/drag or break into circles when minified.
And of course, properly written code should not calc sines and cosines when it isn't absolutely necessary.
.
-
!!! OMG CHARLES !!!
Your FPU job is absolutely awesome! :D
' sdl plasma example on: https://gist.github.com/stevenlr/824019
includepath "$/inc/"
#include "MinWin.inc"
#define SRCCOPY 0xCC0020
! GetTickCount lib "kernel32.dll" () as dword
! CreateDIBSection lib "gdi32.dll" (dword a,b,c,d,e,f) as dword
! SetStretchBltMode lib "gdi32.dll" (dword a, long b)
! StretchBlt lib "gdi32.dll" (dword a, long b,c,d,e, dword f, long g,h,i,j, dword k)
#lookahead
indexbase 0
dim cmdline as asciiz ptr, inst as sys
&cmdline=GetCommandLine
inst=GetModuleHandle 0
' fake BITMAPINFOHEADER
packed type BMPBLOB long biSize,biWidth,biHeight, short biPlanes,biBitCount, byte biUnused[24]
dim as dword XRes = 320, YRes = 240
dim as dword width = 800, height = 600
dim as dword colors[256]
FillColorTable
dim as BMPBLOB bb
with bb.
biSize = sizeof(BMPBLOB)
biWidth = XRes
biHeight = YRes
biPlanes = 1
biBitCount = 32
end with
dim as dword pixels
dim as dword hBmp = CreateDIBSection(0, @bb, 0, @pixels, 0, 0)
dim as dword hDC, memDC = CreateCompatibleDC(0)
dim as dword hOldBmp = SelectObject(memDC, hBmp)
WinMain inst,0,cmdline,SW_NORMAL
end
function WinMain(sys inst, prevInst, asciiz*cmdline, sys show) as sys
WndClass wc
MSG wm
sys hwnd, wwd, wht, wtx, wty, tax
with wc.
style = CS_HREDRAW or CS_VREDRAW
lpfnWndProc = @WndProc
hInstance = inst
hIcon=LoadIcon 0, IDI_APPLICATION
hCursor=LoadCursor 0, IDC_ARROW
lpszClassName = strptr "_Demo for Peter!_"
end with
RegisterClass (@wc)
Tax = GetSystemMetrics SM_CXSCREEN
Wtx = (Tax - width) / 2
Tax = GetSystemMetrics SM_CYSCREEN
Wty = (Tax - height) / 2
hwnd = CreateWindowEx 0,wc.lpszClassName,"OxyPlasma",WS_OVERLAPPEDWINDOW,Wtx,Wty,width,height,0,0,inst,0
ShowWindow hwnd,SW_SHOW
UpdateWindow hwnd
sys bRet
while bRet := GetMessage (@wm, 0, 0, 0)
if bRet = -1 then
'show an error message
else
TranslateMessage @wm
DispatchMessage @wm
end if
wend
end Function
function WndProc (hWnd, wMsg, wParam, lparam) as sys callback
static as dword gtc, fps
select wMsg
case WM_CREATE
hDC = GetDC(hWnd)
SetStretchBltMode hDC, 3 ' COLORONCOLOR=3 HALFTONE=4
case WM_SIZE
width = lParam And &HFFFF
height = lParam >> 16
case WM_ERASEBKGND
return 1
case WM_PAINT
if GetTickCount() - gtc > 1000 then
SetWindowText hWnd, "OxyPlasma FPS = " & fps
fps = 0
gtc = GetTickCount()
else
fps += 1
end if
DoPlasma
return 0
case WM_KEYDOWN
select wParam
case 27
PostMessage hwnd, WM_CLOSE, 0, 0 ' VK_ESCAPE
end select
case WM_CLOSE
DeleteObject SelectObject(memDC, hOldBmp)
DeleteDC memDC
ReleaseDC hWnd, hDC
case WM_DESTROY
PostQuitMessage 0
end select
return DefWindowProc(hWnd,wMsg,wParam,lParam)
end function
sub FillColorTable()
dim as byte r, g, b, i
for i = 0 to 255
r = 255 - (sin(3.14 * 2 * i / 255) + 1) * 127
g = (sin(3.14 * 2 * i / 127) + 1) * 64
b = 255 - r
colors[i] = (b << 16) or (g << 8) or r
next
end sub
sub DoPlasma()
dim as sys p = pixels
dim as dword x, y
dim as double c1, c2, c3
dim as double sn, cs
static as double f = 0.0
SelectObject memDC, hOldBmp
for y = 0 to < YRes
for x = 0 to < XRes
sn = sin(.8 * f) * 160 - x + 160
cs = cos(1.2 * f) * 100 - y + 100
c1 = sin(x / 50. + f + y / 200.)
c2 = sin(sqrt(sn * sn + cs * cs) / 50)
c3 = (c1 + c2) / 2
*p = colors[(c3 + 1) * 127]
p += 4
next
next
SelectObject memDC, hBmp
StretchBlt hDC, 0, 0, width, height, memDC, 0, 0, XRes, YRes, SRCCOPY
f += .01
end sub
P.S. Sorry for the messy tabs, guys. This SciTE thing can be so crooked at times... :(
.
-
...and now ....
super - ultra- de-luxe hi-fi powerful plasma on the world ;D
// ps Mike
// why u use scite anyway?
.
-
Yes Aurel,
This is the fastest plasma possible under Windows. Direct writes into the DIB pixel array with subsequent blitting to the on-screen DC. StretchBlt()/BitBlt()/PatBlt() are hardware assisted API's. BitBlt() would be the fastest but StretchBlt() makes us window size independent. So the only bottleneck remaining is the speed of the two nested loops. And here Charles' FPU math/trigonometry seems to work considerably faster than my DynC (see my earlier screenshots with ~40FPS). That's very remarkable. And I think this code couldn't be working any faster even with a static optimizing compiler.
Why SciTE? Because I think that's what Charles is using for his Oxygen scripts. And what's good for Charles and his OxygenBasic is also good enough for me. :)
-
And Mr Ruben,
The dragging-and-dropping of your .rub scripts onto your ruben.exe interpreter doesn't work for me here and I guess it wouldn't for anybody anywhere else.
Can this annoying inconvenience be somehow fixed, do you think? Regretfully I'm not planning to install your entire setup on my machine but I could run some of your scripts from time to time if they would launch for execution via drag and drop.
-
Because I think that's what Charles is using for his Oxygen scripts.
hmm i am not sure becuase he tell me once that he use notepad....
but maybe i am wrong...
scite is not bad but is little bit clumsey to work .. :-\
-
sorry Mike i don't know why drag & drop not wotk for your win7 system
but i bet that will work with your XP ..or maybe not to ::)
ok you can try this one...
.
-
Aurel,
Actually I'm under my XP now. Drag and drop seems to be showing signs of life only when the .exe (any of the two) and .rub are in my root C:\ directory. But even then, ruben2.exe shows several error messages and stays hanging in memory. See the first of them in the picture. I have to kill ruben2.exe with my Task Manager in the end.
That's rather annoying indeed. ???
.
-
Yes, I use notepad for almost everything. Absurd, I know! I hold stacks of open scripts on the Desktop. But Scite or Oxide will do the job.
-
Hehe Charles,
Delete your Notepad to get rid of the temptation altogether. Then try SciTE for a change. :) (A hint: start right off with adding missing keywords to the highlighter :) )
Oh yes, I guess I can tweak my Code::Blocks to work with OxygenBasic too. <a light shade of irony and reproach> But then what about the SciTE that comes with the distro? </a light shade of irony and reproach>
-
yes Mike that is really strange .
for me work anywhere if both files are inside folder
but only not if they inside MyDocuments ... :o
-
@Aurel - Be careful of paths/filenames with spaces in them.
-
yeah..yeah... i know chr(34) ::)
ok Mike in attachment is everything ...try
.
-
@Aurel - Be careful of paths/filenames with spaces in them.
Yes John, and sometimes there may also be problems with non-Latin characters in the paths to system folders on localized platforms but that's not the case with me. I'm trying it either in the C:\ root or its immediate descendants.
Mike in attachment is everything ...try
Sorry for the delay -- I've been disconnected for a few hours from the net by my IP provider.
No, it didn't work either. You can see me having unzipped it into C:\Rplasma (1). The editor started OK (see my Task Manager with RCode2.exe (2) in it) and loaded plasma2.rub as expected. But trying to press Run button (3) didn't help. Now pressing Compile button (4) or dragging and dropping plasma2.rub on ruben2.exe produced a series of error boxes (5), (6), (7), and (8 ). Then plasma2.rub quit but ruben2.exe remained hanging in memory as in (9) and could be unloaded only with the aid of Terminate Proces button (10).
I do not have either .rub files associated with ruben2.exe, or .o2bas files, associated with gxo2.exe. The effect is also negative under my Vista or Win 7.
.
-
sorry Mike
It looks that something is very different between our OS.es ...strange...
u have XP - sp3 and i use XP sp2.
One guy from my forum tell me that with editor work on his win7 without problem
or is this somehow connected with 02 varsion or something very unusual
like i have problems with Eclecta...maybe ...i really don't know ::)
-
No problem Aurel,
Just try to post snapshots too whenever you submit something of value. This way other users can always have an idea of what the submission is. 90% of useful data comes to us through our vision.
Many indie developers have no possibility to test their creations on every platform and it's not unusual (though somewhat disappointing) that some user might not be able to try them out in full. A screenshot will however compensate for such a deficiency to some extent.
And of course it will also be good for your image; it shows that you care about your audience and the audience will be more co-operative and benevolent in return. :)
-
the audience will be more co-operative and benevolent in return.
well Mike i really doubt that anyone care...
because as you know many great products are abandoned or dead.
unfortunatelly... :-\
-
Hehe Aurel,
So the more valuable are those who are still sticking around. :)