Being Totally Dim
BlitzMax Forums/BlitzMax Programming/Being Totally Dim
| ||
| Hello: Some of the more interesting features I had seen in programs past was the ability to plot colors on the screen, leave a trail, and the trail would erase itself over time. They did this by taking every pixel on the screen and DIMMING it, the whole screen by one brightness level. Now, you would think with code like: SetColor 0,0,0 SetAlpha .05 DrawRect 0,0,768,576That this would work. Unfortunately it does not. It leaves behind a gray trail that does not erase at all. So how can I modify or rewrite this code entirely so the screen is darkened slightly, say by 1-level of brightness) each drawing cycle ? I'd like to avoid reading and writing every pixel on the screen with readpixel() and writepixel() if at all possible. And also avoid just plotting a black circle behind the plotted ones. No, I am looking for code that truly darkens the screen just a little bit each time so you can have a nice trail effect where the colors darken most at the oldest drawn and least at the earliest drawn. Here is the code: |
| ||
| can't you just do it with setclscolor like below in which you reduce the set value each iteration or am I misunderstanding what you are trying to achieve? Repeat r2=Rand(0,255) g2=Rand(0,255) b2=Rand(0,255) Until Abs(r2-g2)>64 Or Abs(g2-b2)>64 Or Abs(r2-b2)>64 ' must be radical color Local c:Int=255 Repeat ' (* MAIN *) SetClsColor(c,c,c) c=c-1 Cls SetColor r,g,b DrawOval x-64,y-64,128,128 ' draw 4-circles mirroring on screen DrawOval 704-x,y-64,128,128 DrawOval x-64,512-y,128,128 DrawOval 704-x,512-y,128,128 Flip |
| ||
| Hi GV, thanks for the reply - but no, that doesn't work. The circles need to leave a trail behind them and only when the trail is long (say 128 iterations) will it turn completely black, not gray as it is now. |
| ||
| An Alpha of 0.05 is probably not suitable. It might be a float, it is used as a byte and when multiplied by the color, it loses so many precision that it can't really clear the screen Try with something like 0.1 or use a shader, it will do the job pretty well. You don't want to peek/poke on the screen for each pixel, but in the end, it's what your doing -> when you draw your rectangle, it's what the CG will do. At least with a shader it won't consume more time and it will give you a better result. |
| ||
| There are only two options (imho): a) manipulate the backbuffer/texture/"screen-graphic|pixmap|..."/ with software-rendering or a shader b) render the "dots" as objects re a) as you cannot rely on existing pixels, you need to have them stored somewhere (texture) - then you could draw on them to darken them "dot by dot". Dunno how it would have to be done with shaders. re b) Each "trail-dot" is an simple object (x,y,color:int, maybe "age:int"). When updating the "trail-dot" you darken its color and render it on the screen (SetColor color;Plot(x,y)). Instead of darkening you could "fade" (adjust alpha). In both cases you could remove the trail-dot when reaching alpha<=minAlpha or color = screenBackgroundColor. minAlpha because you might decrease alpha in a non-linear-way (alpha :* 0.9) and you want to avoid endlessly small alphas still leading to rendered "trail-dots". The more dots you want to render, the more "cpu hungry" it gets. If you would use some kind of pixmap, I assume you would have to send it to the GPU each time you modify it (which happens a lot then) - not the best idea. Dunno what would happen with shaders (upload the new data, recompile?...). bye Ron |
| ||
| Hi Bobysait: No, 0.5 gives even worse and brighter gray trail results. How do I use a shader ? I don't think I've ever used one of those before. Derron: How would I make it a texture ? I've never written code like that before. You have an idea of a method where I erase behind the circles, I'm trying to avoid that, but let's see how THIS looks just of curiosity: Well now you get FLICKER. Very strange indeed. |
| ||
| . |
| ||
| It is flickering because you do not clear your screen - read: you are relying on the backbuffer staying valid between your flip()-calls. Like I told you already: this is not the case. Which is why you need to redraw everything again, each time you render a frame, you have to draw all these ovals. @render to texture I think casaber already copied you the code available in the forums ... there is one for DX and one for GL. You bind the texture then as render target ... render your ovals on it and afterwards render that texture to the screen. Like said I do not know much GPU power it takes as as you of course then have to send a full-screen-sized texture to the gpu each draw call. Assumingly this will still work. bye Ron |
| ||
| I copied Casaber's code, which was copy-pasted of klepto2's code. I then added a "flipped y"-fix to the bind/unbind. Adjusted the initialization (dunno why you should init the graphics in the ImageBuffer - what happens, if you do not use the buffer prior a specific state of the game/app...). important: - the created "render to"-texture must be power-of-2, else (try to remove the pow2-calls) some stretching will happen. - instead of "LockImage(renderToTextureImage).ClearPixels(0)" you do "renderToTextureBuffer.Cls()" - made the code superstrict - your code has some flaws regarding the "out of bounds" bye Ron |
| ||
| Is this the effect you want: (Edit: Misread the post... sorry) |
| ||
| @therevills This is exactly what I thought was intented ... before having a look at the sample he posted (which I had today, when writing my code above). BTW I like this a bit more: 'DrawRect(x - 5, y - 5, 10, 10) local radius:int = alpha * 5 DrawOval(x - radius, y - radius, radius*2, radius*2) bye Ron |
| ||
| No, 0.5 gives even worse and brighter gray trail results. You'd better read it twice. I said 0.05 ;) |
| ||
| Bobysait, .05 is perfect. Results accomplished by using 'memory pieces' thus: Kind of an interesting Fireball effect, with no flicker either. Derron, nothing is getting any darker though. Therevills, yes that effect. Trying to understand your code and I am not. I think I have it here though. Hmm ... I see what you are doing. Perhaps by using an array of all linked pieces and automatically decrease the colors for those. A TMAP might nail it. I need to make sure the circles appear in the correct order. I still think it would be easier if somehow the entire screen could be quickly darkened by 1 color (R-1, G-1, B-1). |
| ||
| OK, here it is using TMAP. I'm not very good with this type of variable storage (only found out about 4-months ago), so this code might seem a little tedious to you veterans: Any ideas on shortcuts would be greatly appreciated as I think this kind of program is a good learning experience for me. |
| ||
| yes that effect. Trying to understand your code and I am not. What parts dont you understand? I tried to make it pretty straight forward. I've noticed in a lot of your code you dont use objects - have you done object-oriented programming before? |
| ||
| Derron, nothing is getting any darker though. It is doing the same as you posted in #6 ... I just replaced "drawing to buffer" with "drawing to texture". It is up to you to have it drawn darker and darker (eg. instead of Cls() the canvas, you could draw a rectangle with 0.01 alpha on it...) To darken it up (so it is more like a fading-out-snake): replace the "bind"-part with: 'clear the previous image content? 'renderTargetBuffer.Cls() '=== RENDER TO renderTargetBuffer FROM NOW ON === renderTargetBuffer.Bind() SetAlpha(0.005) SetColor(0,0,0) DrawRect(0, 0, GraphicsWidth(), GraphicsHeight()) SetAlpha(1.0) SetColor(255,255,255) and the drawing of the texture with: 'draw the render image SetColor(255,255,255) cls 'could be removed as you render a texture to the whole buffer DrawImage(renderTargetImg, 0, 0) Nonetheless it is _no_ final solution (as I did not know what you want to reach). What my sample should have shown to you: - how to use Render2Texture with OpenGL (so you can keep your "backbuffer" by just not calling renderTextureBuffer.Cls()) - how the render2texture functionality had to get adjusted to make the "flipped y" go away (klepto2 never adjusted its code there ... or did he somewhen?) What I did not: - code your idea (as it was not clear wat you wanted to do) - I did not include the objects approach (like I described in #5) - I did not fix your logic flaw (that odd movement when it hits the borders) - but you did it on your own in your other example Render2Texture is useful if you want to manipulate the "last rendered screen" (eg darkening, desaturating, ...). @TMap TMap sorts by KEY ... it is good if you want some kind of "auto sort". Use a TList if you just want to iterate over it. list = CreateList() list.AddLast(myobject) 'add at the end 'iterate over every object for local o:myobject = EachIn list o.Update() if o.a > 0 then o.Draw() next 'remove dead objects by iterating over a copied list 'to avoid concurrent list modification for local o:myobject = EachIn list.Copy() if o.a <= 0 then list.Remove(o) next @Object orientation instead of storing everything in a string, you would then have an object I setup'd your example with some OO ... and small adjustments (got a bit slow on my computer with your very low alpha-decrease) bye Ron |
| ||
| One very minor point is that you are not interpolating smoothly between target colors. The way you are using is obviously a different way of interpolating, one rgb component at a time, but is harder to control if you want to use a specific palette. |
| ||
Therevills: Confession ... No, I've never done object-oriented programming before, it sticks out that much ? Yeah, and - that is one main reason why I do not understand your code. I know my Dad tried to teach me years ago, but I just wasn't - getting it. Like 3D graphics and programming them today. Sure I can toss out an effective and animated 3D star field, maybe a static picture of a 3D rectangle or girder for a logo or something, but no - I have no idea how to actually code 3D or object-oriented programming. The closest I ever came was a routine I always called Nano, a term used in Mork & Mindy for meeting someone. Silly I know. But some of my 'Nano' routines have gotten quite powerful. Not just updating every single thing on the screen but includes comprehensive code for reading keys, mouse, and, back on the Commodore Amiga, Joystick. Back in S2 alone, it's a little over 3,000 lines of code. I imagine I could learn a bit if I understood object-oriented programming, and yet at times my code seems considerably smaller and more accurate than people who code 1,000 lines of something I can easily do in 20. Still, would there by a way to make this code SMALLER by using object-oriented programming ? That might be interesting to see. . . . Derron, Render2Texture is not a command of BlitzMAX. Could you please explain to me what this is - and how to use it ? Reading your code ... I'm barely understanding it. I'm trying though because it looks to me like you've got an interesting type of TLIST in there. I'm wondering why the circles are curving, however, as my code doesn't. . . . Endive, can you elaborate on what you saying to me please ? The code the way I have it is pretty close to what I wanted (or wanted to learn). I think if I can learn Render2Texture and if it does what I hope it does, rapidly effect the entire screen, it might be something worth learning. Still trying to get out of drawing all elements and only drawing 4 circles per cycle with an auto background dimmer. |
| ||
| curving: I added a bit of "gravity" (see the update()-method of TEntity) @Render2Texture This is what Casaber copied you for the "worms"-code. Basically you tell OpenGL to do all graphic commands to a texture instead of the backbuffer. So after you set the buffer as target, a "DrawImage()" will draw the image to be texture. At the end of everything, you have your images, lines, ovals ... on the texture. When you then draw the texture and call "flip()" your whole images, lines, ovals are visible. BUT ... on the next cycle you still have your texture with all that images, lines ... and this allows you to reuse "previous" drawings without the need to re-draw them again and again each frame. In this example it is similar to skipping "cls" (and without the "flicker" because of garbaged backbuffer memory stuff). Advanced usage is eg: - render your GUI-popup-window with caption, texts, buttons ... into one single texture - now you could "scale" the texture when drawing and you will see that nifty "popup-effect" you might know from various casual games. Without r2t you will have to simulate the effect (give the scale information to every child object) but certain things wont work that well (scaling text on a background is a bit jiggery, alpha'd/layers fade-effects wont work). Also it makes it more trivial to create component based images (figures with weapons attached, colorized ...). You wont need to write you own software-render-functions (like I did for my colorize-sprites-functionality). bye Ron |
| ||
So - what I am calling Virtual Screens is actually Render2Texture. Yeah, I wish there was a way to make that code smaller, I.E.:Global hscrn:Texture=InitTexture(0,0,maxwidth,maxheight) ' create hscrn as new texture SetDraw hscrn ' set all drawing to go to it DrawLine 50,50,200,200 ' draw a simple line SetDraw NULL ' set all drawing to go back to NORMAL DrawTexture hscrn,0,0 ' Draw the texture straight to the screen Instead of the monster it is ATM. I'm also reading your new code. Why the gravity ? Is that required if it's an object ? |
| ||
| It is not required...nothing is required. I just added it - to create something "different". global hscrn... this is exactly how it is done currently: Global renderTargetImg:TImage = CreateImage(Pow2Size(GraphicsWidth()), Pow2Size(GraphicsHeight()), 1) Global renderTargetBuffer:TImageBuffer = new TImageBuffer.Init(renderTargetImg) We create an image-object (to work with the image, instead of something unknown, in this case the "TImageBuffer"). We could abstract it to have a "TImageBuffer.Draw()" but for now this should be enough. So we create an image which we want to use as a "render-to-image-target". Next we create that special TImageBuffer-object and initialize it with the given image. This is doing some stuff with OpenGL ... When "binding" we actually say: ok computer, instead of drawing to the (opengl'd) screen, draw to this image/pixmap. When "unbinding" we say, that the screen is the new target again. So after "creating" the buffer, the code is the same as what you want: SetBuffer renderBuffer Draw SetBuffer null DrawImage(renderBufferImage) We just call it with other method names - it is up to you to adopt the code and adjust naming conventions until it fits your desires. And if you coded this whole render2texture-"TImageBuffer" in a module, that code would of course be hidden within a "import bla.imagebuffer" or so. If ... and I say _if_ to make you want to explore that subject, so if you want to understand a bit of OO ... you try some small samples with simple objects - a "TEntity" type, storing "X,Y" when drawing stars (compared to having 2 arrays for X and Y's of all the stars) might be a good start. Then advance to introduce colors, lifetime ... Then change from "TStar" to "TSkyEntity" ...and learn "extends" (TMoon extends TSkyEntity, TStar extends TSkyEntity). OO makes codes a bit more versatile - you want a moon to be drawn differently to a star, so extend the object and override your "Draw()" (or how you called it) method and use a "DrawOval()" instead of "Plot()". While it makes your code a bit _longer_ it surely increases readability. Why? _I_ did not know what you meant with your "yank" function. Keeping things _short_ is in no way a guarantee of being an effective/useful piece of code. bye Ron |
| ||
| Hi Ron: YANK is a routine I wrote years ago that hearkens all the way back to QBasic 1.0 with me. It's pretty straight-forward and an integral part of S2 to rapidly retrieve data that has different sizes of elements. You have a single string, let's say, Fruit$. Now let Fruit$="Apple,small,red" if you call yank$ the return result is "Apple" =AND= Fruit$ changes as well, it is now, "small,red" If you call yank$ again from here the result is "small" and Fruit$ changes to "red" Call yank$ one more time and the result is "red" and Fruit$ is now an empty string. Kind of like pulling a plastic tray out of a metal container, there is a spring on the bottom to push the next item up. I understand what you are saying about image objects. Now here is something I was experimenting with, can this be made into something - and perhaps used in the code you wrote above ? Strict Graphics 640,480 Global scrn:tgraphics=CreateGraphics(640,480,0,0,0) Global i SetGraphics scrn For i=0 To 639 Plot i,240+Sin(i)*120 ' plot some thread Next ' It's plotted to this hidden page, now how do you retrieve it to view on the regular screen ? Flip WaitKey End |
| ||
| Everything after '=== TRENDERBUFFER TYPES === is similar to "imports" - if it were a module, you would "import bla.renderbuffer" and then just use that non-oop-convenience functions (SetRenderBuffer(bla) and UnsetRenderBuffer()) So what is else needed: - you need to create a renderbuffer (else you render to the faked "screenbuffer") - activate the created renderbuffer - draw things on this buffer - deactivate the renderbuffer - draw things on the screen (eg the image of this buffer, some extras like FPS, ...) Edit: adjusted the "bind"-glOrtho-Call, as it contained two times image.Width, which was incorrect. Removing this, also removed the need to create the buffer with power-of-2 images (textures are pow2'd already) bye Ron |
| ||
| Here is another sample - showing how we generate and manipulate an image texture and render it a dozen times then without really affecting the performance. I also prepared some convenience functions - maybe someone writes a kind of "driver system" so it would automatically use "TOpenGLImageRenderBuffer" when OpenGL is used, and a "TDirectXxImageRenderBuffer" for the various DX engines. Easiest would be the integration in the modules so it gets auto loaded then, else we would need to use Reflection to find out which GraphicsEngine is running (as "_driver" is a private property of brl.graphics). One usage for such a Render2Texture is eg a interface texture ... things rarely change on the interface but it might consist of 200 different objects (active unit portrait, money, time, healthbar). If you change one of these values, mark the interface object "dirty" and it recreates the texture, else it just renders the cached interface texture and saves a lot of draw calls. Of course this could be done again with software-rendering, but sooner or later you will reach some troubles (in my case this were alpha-issues and shining-through elements of combined sprites). To repeat myself: the biggest benefit is that you draw on your already existing image ... so you only draw the "deltas", the "changed content". This is then similar to "DirtyRects"-approaches. bye Ron |
| ||
| Here is an absolutely excellent introduction to OO, in Blitzmax. Once you learn it you will never want to go back to procedural code. http://brucey.net/programming/blitz/misc/library/BlitzMax_OOP_Tutorial.pdf |
| ||
| Hi Derron. I'm looking at your code. This is using Casaber's technique, which I'm trying to avoid. Surely there must be a way to plot to a hidden page and recall it in less than 300 lines of source. In my code: I am apparently plotting to a hidden page, I just don't know how to retrieve it. If that can be solved in less than 300-lines of code, that would be wonderful ! Endive, I will look at the documentation. Wish me luck, this will definitely be a first in coding for me, and thanks. :) |
| ||
| It uses so much lines of code because it tries to be versatile (extendable - so it could be used with OpenGL and DirectX or something else). Your "draw + flip" is sending the data to the GPU ... and you need to retrieve it from there, which makes it using the same technique than "grabpixmap" - aka "slow". Regardless of this: it does not matter if you see the 300 lines of code there. If it really matters, you should avoid importing brl.graphics as this imports some hundred lines of code too. Same for a PNG-Loader, input handling ... Just because you are not using the "framework command" you are including thousands of LOCs. Do you blame that? no? So you shouldn't blame 300 LOCs helping you with a render-2-texture-feature. once you copied that "'=== bla" portion into another file it is just Import "renderbuffer.bmx" Global buffer:TRenderBuffer = CreateImageRenderBuffer(w,h) SetRenderBuffer(buffer) 'draw to that buffer UnsetRenderBuffer() DrawImage(buffer.GetImage(),x,y) Flip Is this still too much code for something versatile? I just start to think you do not want to understand it. Just think again what you will have to do if "DrawImage()" (coming from an imported module ...) wasnt available, if you would have to "glTextureBLA" your own things. @Casaber's technique No, he just copied the code, Klepto2 posted somewhen in the forums - including the whitespace - so a straight copy-paste. Edit - your "plot"-code would then be SuperStrict Import "renderbuffer_or_how_you_call_it.bmx" SetGraphicsDriver(GLMax2DDriver()) Graphics(640 , 480) Global renderBuffer:TRenderBuffer = CreateImageRenderBuffer(GraphicsWidth(), GraphicsHeight()) SetRenderBuffer(renderBuffer) For local i:int = 0 To 639 Plot (i,240+Sin(i)*120) ' plot some thread Next UnsetRenderBuffer() Repeat 'do something with the image DrawImage(renderBuffer.GetImage(), 0,0) Flip Until KeyHit(KEY_ESCAPE) Which looks - compared to your code, not very longer (5 lines of code more) bye Ron |
| ||
| Hi Derron, thanks for the code - but no, I was wondering if there was a way to do it without any IMPORTs. So it used only BlitzMAX's own command set. |
| ||
| I do not want to repeat it over and over... if you do _not_ use the framework command, you are already importing all modules available. Without these modules, "plot" wont exist, or "CreateGraphics()". So if you put the renderbuffer-part in a module like brl.mod/graphics.mod, then you would autoimport it too. In your case (your above's sample) you are at least importing the modules: brl.graphics brl.max2d brl.polledinput You are not believing me? disable "import all modules" by doing the following: SuperStrict Framework Brl.Blitz Now up to no "additional command" is available (and the filesize is way lower than without the framework command...). Feel free to read about framework in the various threads available on the forums. bye Ron |
| ||
| No, I understand I can cripple the compiler (or language) from its default libraries. I was just trying to find a nice small code to the solution. I have Casaber's code in place and will use it - I guess developing a hidden page from the code I used below is beyond everyone's understanding to try and get working - it's beyond me anyways. :) |
| ||
| You are able to retrieve it with adding a grabimage after you flipped the buffers. This is how you do it with blitzmax. Keep in mind that Casabers Code flips y-axis and contains a bug using image.width instead of image.height in one line. I will stop replying to that thread as I told you already that drawimage() etc are doing multiple things in the background too (so I cannot add "new things" to this question). R2t is just not provided by blitzmax' provided modules. As a plot() might immediately be send to the gpu you have to fetch the results from there...which is done by these grab-commands. R2t avoids this by redirecting plot/drawimage/drawoval... to a texture instead of the gpu. Bye Ron |
| ||
I'm trying to avoid grabimage or grabpixmap. That's fine - I have the tools necessary to work, I was just hoping to cull it down a little. As mentioned, in GFA to create a virtual screen, it's:dim newdc,bmpdc newdc=memdc(_dc(1)) bmpdc=createbmp(640,480) setbmp newdc,bmpdc setdc newdc ' can now draw to this hidden page ' to copy to main screen use: ~bitblt(newdc,0,0,640,480,_dc(1),0,0,SRCCOPY)_dc(1) is a handle to accessing the main display screen. Now I will tell you, Ron, bitblt() is not part of GFA but of Windows own internal routines, so technically, you should be able to call the same command as BlitzMAX has full access to windows libraries and routines. If that's not a clue to solving the hidden page, I toss my hat to the affair and will use Casaber's routine. |
| ||
| Again: it is _not_ Casaber's routine. It was written by Klepto2 -> [a codearcs/codearcs.php?code=2222]Code Archive Entry[/a] @windows libraries This does not matter, as you are not doing software rendering (manually setting bytes of a memory block / pixmap). I will try to explain (hopefully I am not wrong there): As soon as you call "DrawImage" the corresponding internal commands are used to inform the GPU of what to do (position a quad at XY and use the following texture data). Depending on whether you use OpenGL or DX this is done when doing the "DrawImage" - or when doing the final "Flip" (you could measure it by timing the commands and check which one takes the big time. So instead of drawing the image on a big "screenbuffer-image" and at the end sending this image to the GPU, each of the small drawn images is send on their own to the GPU. THIS effectively avoids a fast "grab screenbuffer"-command. That R2T-Code now does introduce something similar to what "GFA/windows commands" do: it tells eg. OpenGL to target all commands to a texture instead of some gpu memory (I assume _this_ is not working exactly this way ;-)). So it is some kind of "re-routing" the draw-commands. I do not know if this somehow uses the GPU (potential limits regarding max image size) or is CPU only (no limit except memory/RAM). Maybe someone with more knowledge can shed some light on this subject. "Shaders" and other things are there, to instruct the GPU how to manipulate data which is already in the GPU memory (so the "slow" transfer could be skipped). Nonetheless: as soon as you want the data back from the GPU, you will end up with some slowdown (as you need to copy the data from GPU to CPU ..which takes some time). Conclusion: I do not know another way of getting an image as render target (except using software rendering - similar to how I am doing it in my DIG-Framework). bye Ron |
| ||
| Software rendering is also not the worst thing in the world, it can go pretty fast these days. |
| ||
| But this means, you have to code it on your own (multiplication of colors, blend modes, ...) while the OGL-path does this for you already. bye Ron |
| ||
| Klepto2's routine then. In any case, it works and is good - and was definitely one of the main things I missed from GFA. Reading your description ... yes, I'm going to need another cup of coffee for this. I think Mike Meyers said it best in the live-action movie, "Cat In The Hat,"  How did you get so smart ? I am barely understanding this. Endive mentioned software rendering. I know I use software rendering on the PSX emulator and it runs pretty fast - and better than the alternative DirectX library. Let me ask this, when you use DrawImage() or GrabImage() or DrawPixMap() or GrabPixMap(), is that compiled C++ code or compiled machine-language code ? Is BlitzMAX final compilation, Build Option, Minus Debug, about the same speed or slower than C++ ? Is Klepto's routine using the shader method you are talking about, or is there some shader method I haven't seen the source to yet that runs faster than Klepto's ? Still want to thank Casaber for introducing me to the marvel code. I'll credit Klepto when I finish this crazy engine - and everyone else who introduced new code to me that I'll use. :) I'm still not very happy with the massive code I wrote HERE: http://www.blitzbasic.com/Community/posts.php?topic=105561 Got to be an easier way to write a keyboard reader in BlitzMAX that operated with MaxGui.Drivers. Also - reading several posts in here (from other people) there is a lot of talk of trying to maintain compatibility. I know now that BlitzMAX can run on the Macintosh, does it also run on cellphones ? |
| ||
| I know now that BlitzMAX can run on the Macintosh, does it also run on cellphones ? No... but Brucey's BlitzMAX NG does. |
| ||
| BlitzMax NG ? This sounds pretty interesting, Therevills. I'm seeing sources, has someone compiled the latest version and/or link to support page so it can be explored ? Does it compile to HTML5 or some other format ? |
| ||
| The easiest version of BMX-NG is on here: http://www.bmx-ng.com/main/downloads/ I do remember Brucey showing off some Emscripten.... |
| ||
| I'm seeing two versions. To which media does this port ? Windows EXE, Flash, HTML5, or ... ? https://github.com/bmx-ng/bmx-ng/releases/download/v0.70.3.09.win32/BlitzMax_win32_0.70.3.09.7z https://github.com/bmx-ng/bmx-ng/releases/download/v0.66.3.06.osx/BlitzMax_osx_0.66.3.06.zip I appreciate these links ! Something new to explore. I have the Win32 ver up and running. Tried code: Print"hello world" Set Platform for WEB, Compiled. It crashes ... :( Build Error: failed to compile (2) C:/David/DLs/BlitzMax_win32_ BTW, I may have something you would be interested in. My (hopefully) final version of "Serious Key Reader" it's very configurable now. You can specify timers for key repeat and everything. http://www.blitzmax.com/Community/posts.php?topic=105561 |
| ||
| These download describes on which OS they run. For what they compile is written on an other sheet of paper (keyword: "cross-compiling"). On Windows you might be able to compile to: Windows, Android and Raspberry PI (because there are SDKs for last two targets - and they are available cross-platform). From Linux/Mac-Variants of BMX-NG you will be able to compile to: Linux respective Mac + Windows,Android,PI. @Build Error Emscripten ("WEB") is currently not working (GC issues). bye Ron |
| ||
| I couldn't get "Hello World" to compile to ANY platform in that 32-bit Windows edition, including . I know that's getting to be a pattern with me, where things aren't working right I'm downloading - but that's the importance of testing on all computer platforms. I currently have Windows 8.1 64-bit edition. Fortunately good ol' BlitzMAX does work, and well, so - I'm going back to it and finish writing this graphic editor to replace my earlier one from 5-years ago. |
| ||
| Please rename your BlitzMax-Folder to something simple ("C:/David/DLs/BlitzMaxNG") - maybe something did not like the underscores. (at least it looks odd, as your path is truncated (_win32_ [...?]) bye Ron |
| ||
| I couldn't get "Hello World" to compile to ANY platform in that 32-bit Windows edition, including . http://www.blitzbasic.com/Community/post.php?topic=105123&post=1289767 Read that, and if it sounds familiar, go here: http://www.bmx-ng.com/main/downloads/ :) Dabz |
| ||
I appreciate the update, Dabz, unfortunately even this newer version crashes on the simple:Print "Hello World." And - can I ask why it takes SO long to compile ? It's still at 6% as I write this. Now, 12%. That's horrendously slow compared to default BlitzMAX speed of compilation. |
| ||
| Probably depends how old your hardware is... on my computer, a clean build of the brl modules takes 8.5 seconds... A basic app (1 file using framework) compiles in < 1 second. Better to stick with the official BlitzMax. :-) |
| ||
| Compilation might take some time: Use quick compile if possible (official maxide does not offer the -quick compilation flag). Once all modules are compiled it will just compile your code...which is faster (obviously). Nonetheless...without -quick the new bmk checks modules whether they are changed and need recompilation. Bye Ron |
| ||
| Hi Brucey. I'm using a quad-core pentium 64-bit Windows 8.1 Once it did the initial long compilation, it's fairly fast on all programs now. Brucey, this is your brainchild, how do I get it to compile to a web executable without crashing ? And ... doesn't your free program defeat the purpose of Monkey-X ? I mean Blitzmax's own MaxIDE is far superior than Monkey-X's own IDE.  As Ed from his garage would say, "I'm not complaining, just reporting." |
| ||
| And ... doesn't your free program defeat the purpose of Monkey-X ? I mean Blitzmax's own MaxIDE is far superior than Monkey-X's own IDE. Blitzmax-NG is in part based on Monkey's open-sources translate utility, so without Monkey NG wouldn't have existed in its current form either. All in all, Monkey and Blitzmax both have their own strengths and weaknesses. Monkey is supposedly more advanced with regards to its implementation of object oriented programming, while blitzmax has a larger command set especially factoring in the tons of 3rd party modules written for it... But all the additional platforms that were added to Blitzmax NG definitely give it a significant functional overlap with Monkey. |
| ||
| how do I get it to compile to a web executable without crashing ? You would need to fix the issues with BCC-NG and the emscripten target (for now this are issues with the GC ... If ...and only if ... am to trust Brucey on this topic :-)). bye Ron |
| ||
| Xlsior & Ron: I'll definitely wait for Brucey to update then. Way out of my hands - oh, and some bad news about Klepto2's routine. You =CAN'T= use GrabImage() or GrabPixmap() when you are working on a virtual page. Yes, you can draw lines, circles, pixels, and so forth to the virtual pages as Casaber showed, but no grabbing of images AT ALL - I've tried many MANY different ways. Unfortunately that just about shoots my entire use for the whole routine right down the drain. I can write code to prove this problem happens if someone wants to see it - but it's really depressing to look at - so close and yet so far. But I'm not sunk entirely. I can still work with pixmaps that only appear invisibly when something needs to be read out of or written to them. Heh - prior to that I was actually using actual normal arrays that covered the full screen: Global Scrn:Byte[4,1024,768,3] ' page, x, y, color R G B and redrew portions of them depending upon what got changed. My programming is DIM indeed ! :) Fortunately I can program better than that today. |
| ||
| There is no need to grabimage/grabpixmap... the image used for the buffer already contains the content you have drawn before. Like I have told you multiple times: that r2t redirects your draw commands to an image/texture instead of the backbuffer on the GPU. Bye Ron |
| ||
| Let's say for a minute I'm a beginner to modern graphics - because in many ways I think I am. How would I change this program to give the correct results, where it first shows corners (2 blocks apart from each other), then shows what was written and captured from (one bigger block). |
| ||
| http://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0321773039 http://www.amazon.com/OpenGL-SuperBible-Comprehensive-Tutorial-Reference/dp/0321902947/ Also I think you should start considering whether there's some more productive use of your programming time. It seems like you've been spinning your wheels for a while now. What exactly are you trying to accomplish with this piece of code? |
| ||
If it worked correctly, it would be perfect for a graphic editor (what I'm working on now and thinking of sharing with everyone else when it's done). For instance, I am at the part where you press "7" on a field and it scrolls that field with arrow keys using wrap-around pixels. Without this code I have no free "workspace." Instead I must create a new image that displays 2x2 repeat fields, use a fixed field of view, and scrolls and captures accordingly to give the effect of scrolling wrapped pixels for the area you've selected. The virtual code would give me the ability to glide from one hidden page to another, speeding up complex changes throughout all pages overall. For games, you could build 4 or more layers to produce truly impressive parallax scrolling effects as well as multi-layer graphic panes that can bleed images through each other. I'm seeing this code for the BIG picture, and that is definitely for a game programmer, and it would help as once I finish this code, I wanted to make my own IDE. Tossing a 'book' at someone is something I would never do to a fellow programmer - EVER - under any circumstances. You are essentially telling me to frock off and go somewhere else simply because you don't know the answer. When is the last time you told someone, "I don't know ?" As for spinning my wheels, you'd be surprised the amount of code I have archived, a little over 700 individual *.bmx code I've written entirely for myself, many of which manipulate HTML files, generate graphic effects for my art (yes, I'm an artist too), and are toys essentially separate for game and RPG development. In addition that I have a little over 170 *.bmx culled from other members. GFA (which you remember does not work past Windows XP), I have a little over 2,700 programs I've written with less than 80 from other members. Upstairs I use 3 of my GFA programs every day that run in the background to help me with downloads and sort through my writings and other backed up files from 6-different terabyte drives. I'm here to stay. . . . I'm sorry if this comes across as heavy handed. But seriously, how many OTHER people have you told to just go read a book on programming ? That many ? Yeah, just me. That's what I thought. |
| ||
' Proof Virtual Screen Code does not allow for grabpixmap() or grabimage() Above is more or less a proof, that you seem to have problems with reading other's posts.... Please read Post #52 again. There is _NO_ need to do grabPixmap/grabImage as you do not want to grab something from the GPU/screen. Also you could only grab something which is already on the "visible buffer". So it needs a "flip" before you can grab something. If you use that r2t then then everything drawn on it, is already available in the image right after you drew it. But it is not drawn on the "visible buffer" on its own, you need to draw your "scrn" to the screen first. After this, you could even use grabPixmap/grabImage but this is _not_ needed. in your case "scrn" contains the rectangles already. I most likely wont tell you this another time, I get tired of you (implicitely) asking the same question over and over - ignoring what others (in this case - my person) write. It just cuts spare time of other users if you ignore them (assumingly unintended) that way. bye Ron |
| ||
| But seriously, how many OTHER people have you told to just go read a book on programming ? What's wrong with reading books? I have a bookcase full of software development books... |
| ||
| Tossing a 'book' at someone is something I would never do to a fellow programmer - EVER - under any circumstances. You are essentially telling me to frock off and go somewhere else simply because you don't know the answer. The problem is not on our end, the problem is on your end, and it is not a technical problem but a personal problem that has damaged you incalculably in ways you are not even aware of. What you're interpreting as not knowing (and I for one didn't know the answer right off the bat) is in fact the growing desire not to do someone else's work for him. Derron and others have told you the answer repeatedly and you not only seem to be unwilling to listen, you are now getting astoundingly rude again. Believe it or not, we have our own crap to do, and while I am very interested in having really fast accelerated grabimage your attitude is so abominable that I don't want to help. You said that you aren't familiar with modern graphics programming. You are not going to learn opengl or modern graphics programming in general without reading books, and if it's OpenGL you're interested in, it will basically have to be those specific books if you expect to get any sort of real footing in it. I would be pissed off by your attitude but it's frankly just pitiable and pathetic because the reason for it is blindingly obvious. This is at least the third time we've all been through this (requests for help that you turned into fights when you were not spoonfed enough), fourth if we count the insane asterisks thing, and it's quite clear that your attitude is not going to improve. How long ago was it that you were telling us DrawPoly was broken, for crying out loud? Has it even been a week? You didn't want to listen about that either, you wanted to argue and argue, despite having had the answer explained repeatedly. Your response when confronted about your childish behavior was to post pictures of admonishing anime girls. Anybody, please feel free to "toss books" at me at any time. Right now I'm working through the books I recommended, yet again but for the first time in over ten years. I'm also reading Principles of Computer Graphics. Why am I doing this? Because I want to learn and I don't want to have to ask people about everything! |
| ||
| Endive, to take someone's request for help and instead to point out personal characteristics of them and to show how 'uneducated' or in an attempt at defamation - is not to be applauded. You already shut down one thread for derailing it in this manner by insulting other users - and now you are doing it again. "desire not to do someone else's work" That is a very poor way of saying you just don't know. I'm glad I'm not you. I'm glad when someone asks for help I am straight, up forward, and honest with them. I will tell them, "I don't know," or, "I know a little and may be able to help," or, "I definitely know this and can help you with it." And no code is too sacred or too 'it's mine and I don't want to share it.' We're in this helping game to LEARN and teach others, not to withhold. Someone can withhold answers from others and may even brag that THEY know and others don't - but what does that say about the person ? Please don't bother to write me in the future if you are merely going to derail the subject and instead point out personal characteristics of other users in the mere sake and attempt of demeaning them. That is so petty - so unlike a helpful person would be. Brucey, it's not the fact he asked me to read a book, it's the WAY he asked. I have never had any problems when you help me. You are right on the mark - and I appreciate that. It should be patently obvious that Endive and me have what we call in the business world a personality conflict. I won't abide by others going out of their way to insult me, and he won't abide by helping others at the level of which THEY (not him) understand. He's not always this way, he can be helpful, but when he is like this, it's difficult to understand the 'answer' he gives and then he can get angry when asked about it further. I know years ago I was ahead of everyone regarding knowledge of computers, and it did make me smug, jealous, and stingy. Today, I'm the opposite, and it's that much better as people I am open and honest with have always managed to teach me something in return. As I have tutored professionally in the past in college (TCJC NW), I know the importance of talking and teaching at the same programming level my students are understanding. I don't take a BASIC programmer and suddenly try to teach them C++ and then get angry when they don't get it. Many times the answers I have received - I feel like this, and it can be frustrating. Derron, I'm not understanding R2T. I even googled it: https://www.google.com/?gws_rd=ssl#newwindow=1&q=define+r2t+graphics Could you please post an example of R2T in work ? Thanks. |
| ||
| Good luck with ALL that. I'm actually not angry at you, I'm highly amused and again your behavior is pitiable. The above is just another example. |
| ||
| Well I appreciate the fact you are no longer taking personal jabs at me and can laugh at yourself, Endive. That is a step in the right direction of getting along with others. Back on subject, there were many ways proposed to 'darken' the full screen. While I'm certain computers are fast enough to darken the entire screen in one pass by modifying every pixel on the screen, it was shown even using ALPHA at a low transparency plotted with a black rectangle over the entire area did not darken all elements, not really - and unusual graphic artefacts were introduced. The last solution to use a TLIST to keep track of all the elements, display them, and darken them over time chronologically by oldest first, I believe was the chosen answer to this particular question. Thanks to everyone who contributed towards this. |
| ||
| Brucey, it's not the fact he asked me to read a book, it's the WAY he asked. You: "I'm a beginner to modern graphics." Me: "Here are two books." Both the absolute canonical references on modern accelerated graphics, bar none. And you are offended by that. You would rather ask other people to do your work for you, and then get offended at them for not spoonfeeding you enough. The problem is not on our end. It is on your end. |
| ||
| Endive, I'M =TRYING= to go back to topic. Will you do the same, please ? ... I will look over one of your books but I suspect strongly it is over my head. Why am I not surprised ? This is the very first example code they have in the book to introduce you to GL - the essential equivalence of, "Hello World." And the code is actually longer then I captured here.  Now for someone who has only used pixels all his life - what did you manage to accomplish for me by sending me this book ? Yes, I have programmed in C++ (the code above), and you could not have known this, but certainly not at that advanced a level. And - more importantly, DON'T they have a forum to talk about this particular subject, OpenGL, which you notice I have NOT been in yet ? http://www.blitzbasic.com/Community/topics.php?forum=103 How does listing books that are over my head and in a foreign language (not BlitzMAX code) - how specifically does that help me ? Remember the story I wrote about people helping each other ? (In my signature line), you are wanting me to chart the stars in the sky in order to teach me how to catch fish - instead of just - FISHING. And you are also handing me a book on Everything You Ever Wanted To Know About Fishing - except that it's written in Chinese. I know you can see this. If and when I enter the OpenGL forum, then you can berate me on how little I know if and when I ask for help in there, fair enough ? |
| ||
| r2t: google: render 2 texture first hit: http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-14-render-to-texture/ --- You asked for another approach to your sample - I wont recode it again (or similar). You asked for an approach to darken an area and to draw new things on it. Code that darkens "previously drawn ovals" (including some comments): (hit "SPACE" to disable drawing the renderbuffer - if you hit "SPACE" again, you might notice that the drawing to the buffer continued meanwhile...) What it does is - what all other samples above did: - it sets an renderbuffer as render target - draws something on it (in this case a slightly visible black rectangle - to darken the canvas / previous image content) - draws ovals at random positions (every 3rd frame - to see the effect a bit better) - removes the screen as render target (rendering to screen again) - draw the renderbuffer to the screeen - flip (-> show on screen what we have drawn to the screen since last flip - in our case this is just the "renderbuffer image") _Your_ logic has to get placed in points 2 and 3. For moving dots you just move your "current position" and draw it with the most current color. Every "fading action" is done through the "drawRect()" which lowers brightness of the canvas. As long as we do not clear the pixels, the canvas keeps what we have drawn on it (this is _not_ the way with the normal screen target... which is why we introduced that render2texture). If you wouldn't try to justify yourself, you would search a bit more smart than just for "r2t". The principle is the same: instead of the GPU you want to render everything to an image or texture. @"yank()" I already understood what it did when reading the function's content - I just was not aware of it when reading "bla = yank(blubb)". I think a "value = popValue(commaSeparatedValues)" is easier to understand (and "push" / "pop" are common commands in programming - think of stacks). bye Ron |
| ||
| How does listing books that are over my head and in a foreign language (not BlitzMAX code) - how specifically does that help me ? The question you are asking has to do directly with OpenGL. Also you had stated that modern graphics was new to you. This is the second question you are asking in which you are accusing the underlying libraries and blitzmax code of being flawed when the problem stems from your personal misunderstanding of OpenGL. Remember the story I wrote about people helping each other ? (In my signature line), you are wanting me to chart the stars in the sky in order to teach me how to catch fish - instead of just - FISHING. And you are also handing me a book on Everything You Ever Wanted To Know About Fishing - except that it's written in Chinese. I know you can see this. And what you're doing is biting the hand that feeds. Also I disagree-- the book is written not in Chinese but the language you need to understand in order to understand the answers to your own questions. It's an instructional manual on the language. Maybe not now but sooner or later you are going to need to read them if you want to understand. Sooner is better. I suggest you start with the chapters that cover polygon winding order though that is back to the other thread. And that's not giving a man a fish, it's teaching a man to learn how to fish. Don't look a gift horse in the mouth, and don't be the one that is led to water but refuses to drink. |
| ||
| I will examine Polygon winding, Endive. Derron, your code does not make the circles go away completely. That is what I was trying to achieve (from the first post in the thread). Your code visually can be recreated thus: Strict Graphics 768,576 SetBlend alphablend Repeat SetColor Rand(255),Rand(255),Rand(255) DrawOval Rand(768-50),Rand(576-50),50,50 SetAlpha .01 SetColor 0,0,0 DrawRect 0,0,768,576 SetAlpha 1 Flip 1 Until KeyDown(27)I will investigate this portion you typed of: Global renderBuffer:TRenderBuffer = CreateImageRenderBuffer( GraphicsWidth(), GraphicsHeight() )As your definitions appear to be something useful to learn, thank you. @Yank, this is the name I've used for the function since I first started programming. Your name is more accurate admittedly. As you are saying Push and Pop are common in programming, there is then a way to increase clarity and decrease code size for my routine but maintain the same results - using some PUSH or POP commands ? ' >> RETURN COMMA DELIMITED TEXT FROM A$ Function yank$(a$ Var) Local b=Instr(a$+",",","),c$=Left$(a$,b-1) a$=Mid$(a$,b+1) ' also remove it from input string Return c$ EndFunction |
| ||
| We all know it's an immensely complex subject but if you want to learn it there is no other way than to do the same thing you did in 1981 when there was no net and there was nobody to ask and there were no good learning materials. There is still no easy answer but the way to get there is lit so much more brightly now that it's not even funny. I am having some trouble going from 2005 OpenGL to modern OpenGL, it is that different. But at least there is good learning material. |
| ||
| As I posted in #5 you cannot rely on the screen buffer contain valid data. That is why leaving out "cls" does not work on all computer setups. So your examples are all flawed on these computers ... Why are my circles never completely vanished? Because we only darken them by 10% on each DrawRectangle (Setalpha 0.1 -> keep 90% of the old content). As you might know infinitesimal calculations, we will have "oldColor * 0.9^amountOfTimesDrawn" - leading to a value never reaching 0. So the end result is, that it is never cleared completely, but somewhen it should vanish into "< 1" (of 255) which means "0". Another option is, that "SetAlpha 0.01" is already that low, that during blend options calculations (whatever OpenGL is doing then...) run into problems. If you adjust that "SetAlpha 0.01" to "SetAlpha 0.05" the effect will be different (the ovals are fading way faster ... but this time completely). The problem is: my approach seems to be valid, but "somewhere else" it is doing some bugged math. I think the problem is this: ContentPixel is eg. rgb=2,2,2. We now draw on top of this with 1% opaque color rgb 0,0,0. So the mixture is this: (100-1)%*2 + 1%*0 = 1,98. The resulting rgb is rounded - and it becomes... 2. What is the effect then? the ContentPixel will never go below 2. -------- BUT ... What I absolutely do not get is: why you are blaming the circles not going away completely - instead of accepting: hey, they fade, but they just do not go completely, so is there a step missing? Such a phrase would let me feel as if my examples are not staying unread. Without this, it sounds similar to: - copy paste code to maxide, compile and run - does not work perfect - post reply on forum that it does not work similar to what was wanted - do not tinker with the code, adjusting values, see what it does ----- Repeating myself: your code does not work on many computers (especially when graphic contexts get destroyed - alt+tab with other graphical apps). ELSE we all would have come with better / shorter code blocks. The only valid option to really "fade out" the whole dots is - like I have described in Post #5 - using objects (and TLists or Arrays/Pools for storing them). Once you run into performance trouble, you could "cheat" by using both approaches: - use the "quick n dirty" render2texture - store objects (but do not draw them directly to the screen) - every X frames you clear the renderbuffer-image and redraw the alive objects on it The interval defines the performance hit. @Push/Pop It is just _me_ who does not understand the word "yank". So for _me_ "pushToCSV(csv:string, value:string)" or "popFromCSV:string(csv:string)" would make more sense. As you mentioned simple code (you present to others...) I thought "readability" should be of concern. Whacky "magic calculations" are not really readable. bye Ron |
| ||
| Yank is supposed to refer to pulling something out from the middle of a stack if I remember right. It's an ancient idiom that dates from the stack-based computing days (1960s?) I had no idea what he meant either at first, it wasn't just you. |
| ||
| dict.cc just told me that its meaning is similar to "pull". So it is surely something people are used to say ... but _I_ was not aware of this. Especially with variable names like "a$" it makes it just a bit hard to read (short but less "self explaining"). Thanks for the explanation. bye Ron |
| ||
| dw is really a very competent and knowledgeable programmer from 1983 who has been mysteriously transported from 1983 in a puff of that 1980s new motherboard smell and a swirl of pages from Incider! Magazine. |
| ||
| Endive, now you're just being facetious. :) At least I don't critique and insult others' coding, I could start - but I really don't want to lower myself to your level, at ANY cost. So - no, that's not going to happen, applicable though it may be. When you two can stop hosing each other down with cerebral testosterone, and actually decide to HELP people, I may return later. |
| ||
| Cool! In the meantime, read those books and the excellent OO guide. |
| ||
| Re: Push/Pop. When I see push and pop in code, I think more of a LIFO structure, whereas it appears that dw is using a FIFO. So if I were to see Pop("Cat, Dog, Chicken"), I would expect "Chicken" to be returned. Of course, I really can't tell by looking at the string as to which order everything was added. Was it "Cat" "Cat, Dog" "Cat, Dog, Chicken"? or "Chicken" "Dog, Chicken" "Cat, Dog, Chicken"? (I'm assuming the first). Honestly didn't know the terms used for adding and removing from a FIFO stack, so I did a bit of Googling. Turns out, it is Enqueue and Dequeue. Thinking I'd might prefer Yank. :) |
| ||
| Maybe this is why Mark used "AddLast" and "AddFirst" in TList - instead of "pull/yank/push/pop/...". @Lifo https://en.wikipedia.org/wiki/Stack_(abstract_data_type) Seems you are right, for me it is translated to German similar as "give" and "take" - which does not indicate a LIFO/FIFO-approach. Seems I learned something new today, thanks. bye Ron |
| ||
| When you guys can finally get over the single word I chose for a function(), I think you'll see I have already started to learn CreateList() and ListAddFirst() earlier today. Yank() may not be needed, we'll see. |
   |