cntools / rawdraw Goto Github PK

I have the following program that draws three rectangles (test.c, I could only add it zipped)

test.zip

The problem is it draws only the outline:

When there is an extra CNFGColor() instruction, the rectangles are drawn filled, correctly:

In the test program this is togglable with 'd'.

I used the rasterizer up until now, but then i realized, it hogged the cpu a lot, so I switched to ogl.

My polygons went from looking like this:

To looking like this:

I use an old nvidia gpu on linux. I thought, that might have been the cause, but after running it on my secondary laptop with intel gpu it still didn't work.

Please consider adding Vulkan support, since it's a newer API that takes advantage of the advancing hardware. In terms of performance, it's better than OpenGL, and also consumes less power, which is especially important for mobile devices. Also, if it's not a stretch, could you possibly just replace OpenGL entirely with Vulkan?

P.S. I'm a novice when it comes to software development, and I don't possess in-depth knowledge of this field yet, so I'm not entirely sure what's possible and what's not.

For some reason, when launching the example after building it for windows, it'll show a black screen where only the text is visible, and you can see the triangles (altough black) rotating on top of the text.

Console output is normal.
Windows 10.
Compiled from Kali linux WSL.

I suggest to reuse a higher level build system than your current make script so that powerful checks for software features will become easier.

• CMake
• Autotools

Currently it expects MINGW32:

Some time ago I stumbled upon https://github.com/audulus/vger and seeing you missing support for Apple ecosystem I thought you might give it a try (or not).

Or maybe even some broader cooperation might be feasible...

Does it support transparency? If not is it possible, that I could make pixel with value for example 1 fully transparent, or is all that left to opengl?

I appreciate that this is most likely not an issue with this LIB but I am hoping someone can see if I have made any obvious errors.

I installed home-brew and everything like X11 was compiled from source for M1. I am then trying to compile the example using the following GCC command. This is where I think the issue is but I cant for the life of me work out what the issue is.

gcc program.c -v -I /opt/homebrew/include/ -I /opt/homebrew/opt/xorgproto/include/ -I /opt/homebrew/lib/ -I /opt/homebrew -lm -lX11 /opt/homebrew/Cellar/libx11/1.7.0/lib/libX11.6.dylib

I have been trying to get this to run now for over 5 hours so if its something obvious then I will cry my self to sleep.

What I cant understand is why it cant find symbols for ARM64 when all the libs were compiled on this machine.

Any help is appreciated

Would you like to add more error handling for return values from functions like malloc()?

I consistently see four HWND where messages get sent to. The current windriver in CNFGHandleInput() only checks CNFGlsHWND, but this misses most events. Especially keyboard events.

I added some output to CNFGHandleInput() of processed and ignored events. So ignored events here are ignored because the HWND isn't CNFGlsHWND.

PROC    HWND    260710  other
PROC    HWND    260710  other
PROC    HWND    260710  other
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    0       other
IGN     HWND    3a062e  other
IGN     HWND    0       other
IGN     HWND    0       other
IGN     HWND    260710  key
IGN     HWND    3a062e  other
IGN     HWND    1d061a  other
PROC    HWND    260710  mouse
PROC    HWND    260710  other
IGN     HWND    260710  other
IGN     HWND    3a062e  other
IGN     HWND    260710  key
IGN     HWND    260710  other
IGN     HWND    3a062e  other
PROC    HWND    260710  key
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    260710  key
IGN     HWND    260710  other
IGN     HWND    3a062e  other
PROC    HWND    260710  key
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    260710  key
IGN     HWND    260710  other
IGN     HWND    3a062e  other
PROC    HWND    260710  key
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    3a062e  other
IGN     HWND    0       other
IGN     HWND    1d061a  other

I added a commit to my previous pull request that sets the second argument of PeekMessage to NULL, which fixes this.

Need to detect failed X initialization to prevent crash.

While looking into cntools/cnping#54 I noticed that the CNFGOGL flag changes the way the font looks. I assume that it is an easy fix somewhere below https://github.com/cnlohr/rawdraw/blob/master/CNFGFunctions.c#L275 and I intend to fix this myself, but everyone feel free to outrun me with a fix.

When I compile my code in windows I get the following warning
the file is CNFGWinDriver.c line 274
The code works just fine

Simple solution is to import ctypes.h in that file, after that the warning was gone

Also, consider making two different Bitmap functions.

For a fullscreen window on Windows:

1. Call CreateWindow() with WS_MAXIMIZE | WS_POPUP instead of WS_OVERLAPPEDWINDOW
2. Call ShowWindow() with SW_SHOWMAXIMIZED instead of 1
3. Call CNFGSetup() with the monitor's resolution (not sure how to get the width and height automatically)

Just to document that cntools/cnping#54 is also present in rawdraw.exe.

Easy workaround (also better fps) is to use OpenGL by adding -lopengl32 -DCNFGOGL as gcc flags.

Is it worth to chase this one down while OpenGL seems to work better altogether? Or is it better to just build with OpenGL by default?

It would be useful for OpenGL on Android, Linux and Windows to use the triangularizer from WASM. It efficiently turns all draw calls into a single stream of triangles.

Line 18 has:

if( keycode == 65307 ) exit( 0 );

it should be:

if( keycode == 27 ) exit( 0 );

@elfring in another thread discussed compliance issues within os_generic. I would like os_generic to be as compliant as possible to aid it's adoption in other projects.

What tools do you use for compliance testing? Is this something you can help facilitate?

In cases where OpenGL is not available (but the executable is built for OpenGL) it would be nice to get an error message instead of a crash. This happened to me on a Windows virtual machine.

Maybe a silly request, but can you add some documentation in the readme or add a wiki?
It'll help people like me whose coding skill is intermediate to get started a little bit easier.

I am trying to update Colorchord to use the latest version of rawdraw. However, colorchord uses the box functions that were removed in commit d32ba81, specifically CNFGDrawBox(). What is the proposed solution to this, are there any alternatives to these functions available? Long term this seems like functionality that would be in RDUI, but that really isn't here yet.
Thanks,
-Sam Ellicott
Soli Deo Gloria

I should probably stop making issues so frequently :], but images are important to me.

I tried drawing some images, but realized, the performance isn't good. 1920*1080 image can take about 6 or 7 ms, and uses a lot of cpu. Is this a known issue?

Btw, I use GNFGOGL. It seems like rasterizer has smaller overhead, but performs worse with bigger images.

Hello,

When you press shift on for instance the GBoard virtual keyboard, it inserts a semicolon.

Looking at CNFGEGLDriver.c, it's because:

• Semicolon has code 74 and unicode 59.
• Shift has code 59 and unicode 0.

In both cases HandleKey receives 59.

Another conflict I found is with 'C' and backspace. Hacker Keyboard shows there's technically more, but they aren't used on Android (e.g. home/end, pgup/pgdn, alt + key, ctrl + key, num lock, scroll lock).

Defining ANDROID_USE_SCANCODES loses the information in event and gets too messy with having to maintain the state of the keyboard yourself. For instance Hacker Keyboard has Caps Lock if you press shift twice (so the graphics are all Caps), but GBoard does not.

I'd like to propose that handle_input() did

if (!AKeyEvent_getAction(event))
	HandleKey(code, unicode);

Because it looks like bDown isn't useful at all with a virtual keyboard. It always sends a two events with a 0 and then a 1 for bDown.

Or that handle_input() added exceptions for these conflicts (at least for shift and backspace).

Image is being wrapped when correct size is given.

when imgWidth = 320 and imgHeight = 240
CNFGBlitImage(current_image, (screenx/2) - (imgWidth/2), (screeny/2) - (imgHeight/2), imgWidth, imgHeight, 4);

I added a comp input to CNFGBlitImage for RGB and RGBA.

I am new to opengl, so I'm a bit lost as to what is causing this.

example screenshot of issue.

I would like to point out that identifiers like “_CNFG_ANDROID_H” and “_DRAWFUCNTIONS_H” do not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

create makefile target for wasm/emscripten

When compiling rawdraw on Windows with clang and the CNFOGL option enabled, the test program simple.c crashes when calling CNFGglCreateShader. However, the problem is coming from trying to load the opengl extension functions (CNFGLoadExtensionsInternal). Calling CNFGGetProcAddress always returns a null pointer instead of a pointer to the opengl function.

The command used to build the test application was:

clang simple.c -o rawdrawogl-clang.exe -g -O1 -Irawdraw -DCNFGOGL -lopengl32 -lgdi32 -luser32

Referencing #26 - We want to enable HTML5 targets for rawdraw, however, I do not want to require use of the enormous use of the emscripten runtime, which can take quite some time to load, verses an approach like I've taken here: https://github.com/cnlohr/wasm_integrated (You can also see the various branches I've tried to do things with).

Basically, I want to enable use of rawdraw with a bare bones minimal runtime, but allow users to link directly to javascript functions as they see fit. It provides for a very, very fast page load time, as it does not take multiple-round trips.

This repo already shows a demo for how to make a minimal web page that links C code to HTML + JavaScript. This is the sort of architecture that will be needed to follow-through.

Rationale: Though "wasm_integrated" works well and efficiently, it requires the return from main in order to allow frame animation. This is incompatible with the fundamental idea behind rawdraw. Rawdraw requires the animation frame to happen during the execution of CNFGSwapBuffers()

I encourage people who are seeking this to read Kripken's blog post here: https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html and see if they can get the first section to work within the scope of this bounty. I was unsuccessful.

What is prohibited:

• You cannot use asyncify as it stands as part of the rest of emscripten because it requires a LOT of code on the javascript side, and several hidden modules which add to load time and file size load. If you can successfully extract only the stack functionality from ascyncify, that is acceptable. I was unsuccessful.
• You cannot use the rest of the huge standalone library, please make it using a similar output mechanism to "wasm_integrated"

11/5 UPDATE Part of the bounty has been claimed, items with an X next to them are currently ineligible for bounty collection

Here is the bounty:
❌ Base: $75 USD for demonstration in wasm_integrated style project, which will make it so when you call CNFGSwapBuffers(), it will pause execution of the C code, and return back out of main to allow the browser to continue to execute all normal functions. But, attach to window.requestAnimationFrame() to continue execution once the callback is called.

• Bonus: +$25 USD be able to write arbitrary WASM assembly code and link into the project, and call the functions from C.
  ❌ Bonus: +$25 USD if this generalizable. As in, you can write javascript function which can return control execution to the webpage and be re-entered into using some sort of state. I.e. if you can make generalizable coroutines working!
• Bonus: +$50 USD if you can make this all work with just llvm, and not involve emscripten.
  -> I recommend forking wasm_integrated and making a branch where you demonstrate your solution.

Upon completion and verification, I, Charles Lohr will personally pay out via paypal, or check.

References:
This looks really key, but I was unsuccessful in its implementation: https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html
emscripten-core/emscripten#12005
emscripten-core/emscripten#12006
https://stackoverflow.com/questions/63421909/em-js-cant-export-functions-in-emscripten/63432057#63432057
https://emscripten.org/docs/porting/asyncify.html#making-async-web-apis-behave-as-if-they-were-synchronous

EDIT rasied bounty for avoiding Emscripten altogether an extra $25.

There is some key overlap with the function keys on Windows. I noticed this with function key F2. It has keycode 0x71. The key 'q' also has this keycode.

The way to tell them apart lies in msg.lParam (in CNFGHandleInput()):

https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-keydown

Bits 16-23 of msg.lParam are the scan code.

Just to test it, I put this scancode in bDown and that makes it workable. (So then I test for two variables when handling keys)

What would you think of some kind of generalized approach? Like having the keyboard on Windows and Android all use the keycodes (and handling) of Linux? Or defining a bunch of globals like CNFG_KEY_F1 or CNFG_KEY_BS (but not for alphanumerics), or maybe having keycode be an enum?

I could try to write something like this, if you want.

I tried fontsize.c in the examples folder.
I've managed to get all the paths and dependencies rectified, and then I get a:

fontsize.c:9: error: include file '../CNFG3D.h' not found

I cannot find CNFG3D.h in the repository, and I tried just including CNFG3D.c, and separately putting:

'#define CNFG_IMPLEMENTATION'

at the top, like in the README example, but it doesn't work.

I am no C expert, so just wondering if I am missing something.

I love that 21 lines can produce a WIN32 window! Thanks!

Hey man, was looking at channel3 and this was included in it. I'm looking into making a small game loop for it and would love any pointers you have for using rawdraw.

I believe I have found a small error in the way hex colors are handled in CNFGColor. Specifically, from my testing, the red and blue values seem to be swapped.

For example, a color 0x0066ff in RGB should have no red, some green, and show up dominantly blue (can confirm with an online color picker such as https://www.w3schools.com/colors/colors_picker.asp). However, using CNFGColor results in an orange color being displayed.

If I mix around the hex number I give it, and instead feed BGR like 0xff6600, I get the blue I intended.

Checking the relevant code snippet confirms this (CNFGFunctions.c, line 339):

uint32_t CNFGColor( uint32_t RGB )
{
        unsigned char red = RGB & 0xFF;
        unsigned char grn = ( RGB >> 8 ) & 0xFF;
        unsigned char blu = ( RGB >> 16 ) & 0xFF;
        glColor3ub( red, grn, blu );
        return RGB;
}

As seen in this snippet, the 0xFF mask is being applied to the RGB value. In effect, it states:

red = (RR GG BB) * (00 00 11) = BB

The variable red is being filled with the blue values of the color. grn, being in the middle, is filled correctly. Finally, blu ends up receiving the red value.

I wanted to put this here in case my logic is somehow flawed or in case there is an underlying reason this is being processed this way. If you like, I can send a PR with the (very minor) edit - otherwise, it should just consist of swapping red and blu:

uint32_t CNFGColor( uint32_t RGB )
{
        unsigned char blu = RGB & 0xFF;
        unsigned char grn = ( RGB >> 8 ) & 0xFF;
        unsigned char red = ( RGB >> 16 ) & 0xFF;
        glColor3ub( red, grn, blu );
        return RGB;
}

Thank you for this awesome project, and I look forward to hearing from you.

At least on Linux, when I hit the exit button, rawdraw.c will not close. This problem is likely caused by some internal change that makes the program not automatically close down when the button is pressed. However, rawdraw.c hasn't been updated to reflect this. I've narrowed this down to simply changing the condition in the program's main while loop to CNFGHandleInput()