Messages

It could be good option to give Steam buyers (at least those who wont) chance to use this forum. Steam community discussion forum (or whatever it's called) is good, but let me say it, this forum will be more active and users would get answered faster, specially as not everyone is looking at Steam so often.

Ah my bad, forgot about Your project, it's excellent example of what you can achieve from such kind of tools with as You said additional work like cleaning and so on. In previous post I should rather say that such tools wont give perfect pixel-art out-of-box, but with additional work, still both those great examples shows 3d software that's exporting to pixel sprite, pixatool takes only 2d images so have limited abilities. I saw what it can do in some pixel detective game, but those two examples from 3d modeling apps looks much better in my opinion.
My conclusion is that even such tool as pixatool won't help me as I just can't draw or make nice 3d models

I saw that tool (pixatool), played a little with demo, and in this form in my opinion it's mostly for textures, static images and some artworks, better solution would be this Blender plugin/shader as it looks closer to real pixel-art. But thinking about real pixel-art for games I rather think about 32x32 tileset, or 64x32 character or something little larger and to getting readable and nice looking sprite with this tools could be hard to achieve, as they prefer larger image outputs, something that would fit as cover, menu background, character portraits... On other hand they would do great job in full-hd/4k pseudo pixel-art games so of course there is a field to show off for them. Best example for pixatool would be some wolf3d clone, this app could be use to do 'create' all textures.

Yep this file works, and now I see what was the issue
Both FOR loops in main function are fixed to this image dimensions - 320x240px, despite checking sprite size with GETSPRITESIZE. How could I miss that :/
Easy to fix and now works great :-) And now I know where to use this with combination of Your FastMem2Sprite - or that Shader version by Gernot Thanks!

Looks good, and it's working without issues. Only one note, camera zooming could be more fluent, now it looks like zooming steps are little to high for small objects :-)

I mean input bitmap that I'm using is 24bit bmp GLB logo, and the result/output bitmap 'test.bmp' is also 24bit with full color range, checked with gimp - same as result drawn on screen when running this code. hm.. probably some mismatch from pasting code but can't find it :>
Strange, because changing to integers should give speed up around 25%-30%, double checked on my pc, and btw. didn't noticed that also some other variables are floats, at least in this code on forum..

Code (glbasic) Select Expand

LOCAL mindist%, dist%, ibest%, i%
LOCAL c64_pal%[]
that gives speed bump from 22ms to 11ms, on my i5.

hm.. according to help file the result of MouseAxis is Integer, but MouseState returns floats, interesting..
Mostly I'm using MouseState in my projects so didn't encounter any issues with that, if I remember correctly, only in one project mouse wheel is needed - for zooming, but with short test I didn't noticed any problems either, will need to take a look into it later.
btw. leaved pc for 15 minutes with that basic tutorial code, buttons and wheel response are ok, only that issue with mouse x&y velocity - it's zeroed when cursor hits screen bounds - when windowed.

Am I missing something? As both pure in-code effects doesn't work for me :/ bitmap remains unchanged (24bit bmp GLB logo). Or maybe there is something more to this code as not all variables were declared, probably I'm blind
On other hand, change 'c64_pal' array from floats to integers -> "LOCAL c64_pal%[]" as this should fast it up to 15ms..

Compiling multiple source files at once was one of new features in v15 if I remember correctly or maybe even in previous version, looks like v16 is running same number of threads as v15 - at least for my 13 files project, yet it's around 50 additional processes so it can hammer even i3 processor. It's good when You have minor changes in project and only few files need to be recompiled, but with more files or fresh compiling it can be disaster for lower spec pc. So it would be nice to have option / switch to disable this function or limit it to compile something like 2 - 3 files at single time.
btw. my editor doesn't have this feature, it still sits in old single file compilation cave

I noticed that issue, it's more visible when running in windowed mode. Looks like mouse cursor isn't grabber properly and when you move it to the edge of screen (it's visible as other windows/system ui are hovered) the velocity is 0, even if you still move mouse in that direction. Maybe some trick with SetMouse would fix this, checked on v14 & v15, same result.

If You didn't uninstall v14, then both versions will sit in same 'Start' submenu, or only v14 will be available there (yet both versions have separate entries in installed programs list). You need to find proper GLBasic_v15 directory in Your 'Program Files' and make new shortcut for editor. Same 'issue' here as I've 3 different versions of GLB installed currently, but this isn't a real problem.

GLBasic version 15 is available on main site in download section, it states thats v14 but it's installer for v15, v16 currently is available only on Steam.
v15: http://www.glbasic.com/files/glbasic_sdk.exe
Basic tutorial code like this is enough to see the issue?

Code (glbasic) Select Expand


WHILE TRUE
   PRINT "X:" + MOUSEAXIS(0), 0,  0
   PRINT "Y:" + MOUSEAXIS(1), 0, 20
   PRINT "Z:" + MOUSEAXIS(2), 0, 40
   PRINT "A:" + MOUSEAXIS(3), 0, 60
   PRINT "B:" + MOUSEAXIS(4), 0, 80
   PRINT "C:" + MOUSEAXIS(5), 0,100
   SHOWSCREEN
WEND

didn't have time to check this :/

It isn't so slow, but it depends on what you want to achieve, maybe playing with pixel format type would help somewhat if full ARGB isn't needed, and pure c++ array may be faster than passing pointer to GLB array.
result on tablet with Intel x5-z8350 and Intel HD Graphics: 120fps

I know that v14 has some strengths in compiling for mobiles but is there any special reason to use v14 on pc? Does it appear also in v15/v16?
Do You have any portion of test code to verify this issue on other setups?

500fps on desktop (i5-3470, Radeon 7750), and I think that it's locked for it in app or driver.. didn't test on laptop and tablet with Intel HD, but if You want can do this later. Your are using function similar to mem2sprite? interesting ;-)

So Steam will be only official way to get GLBasic and future updates, or v16 will be also available as standalone app like now and will follow within few days here too?
On one hand it would be nice to get Steam key as long-time user, on other hand Steam algorithms separate users that bought product directly on platform from those who got it from other sources...

Google Translator is sufficient for such basic review translation