1. Allegro Wrapper?
- Posted by Icy_Viking Sep 14, 2022
- 1281 views
- Last edited Sep 15, 2022
Hello all,
So recently after looking through the updated documentation of Allegro, I have thought about making an Allegro wrapper. Now I know I did in the past, but its old and the codebase is just ugh. So I would rather start new with the most recent version of Allegro. Just wondering if anyone would use it or have use for it?
Codebase wise it would be similar to how the C version is. Each would have its own .e include file. For example: base.h would base.e and would contain the Euphoria code equvialent for wrapping DLLs.
2. Re: Allegro Wrapper?
- Posted by ChrisB (moderator) Sep 15, 2022
- 1250 views
Yes, I love Allegro, just wish I had more time to program (anything).
3. Re: Allegro Wrapper?
- Posted by ghaberek (admin) Sep 15, 2022
- 1249 views
Hello all,
So recently after looking through the updated documentation of Allegro, I have thought about making an Allegro wrapper. Now I know I did in the past, but its old and the codebase is just ugh. So I would rather start new with the most recent version of Allegro. Just wondering if anyone would use it or have use for it?
Codebase wise it would be similar to how the C version is. Each would have its own .e include file. For example: base.h would base.e and would contain the Euphoria code equvialent for wrapping DLLs.
As I recall, Allegro has the same problem as Raylib: it passes a lot of structures by value instead of by reference, e.g. al_map_rgb() returns an ALLEGRO_COLOR struct which is four floats.
Euphoria currently isn't equipped to pull that off the stack, but it can be. I think we need to work on solving this first instead of relying on hacks or shim libraries.
Most of my time recently has been spent pouring through the source code and picking at things to see how they work.
I will see if I can graft in libffi to replace the existing routines. That should allow a lot more flexibility, broader compatibility, and less work to understand calling conventions, etc.
Another thing we need is a better approach to wrapping C libraries. I've recently revisited IUP and I think I've got a good foundation sketched out for general-purpose C-to-Euphoria wrapping process.
-Greg
4. Re: Allegro Wrapper?
- Posted by Icy_Viking Sep 15, 2022
- 1233 views
Hello all,
So recently after looking through the updated documentation of Allegro, I have thought about making an Allegro wrapper. Now I know I did in the past, but its old and the codebase is just ugh. So I would rather start new with the most recent version of Allegro. Just wondering if anyone would use it or have use for it?
Codebase wise it would be similar to how the C version is. Each would have its own .e include file. For example: base.h would base.e and would contain the Euphoria code equvialent for wrapping DLLs.
As I recall, Allegro has the same problem as Raylib: it passes a lot of structures by value instead of by reference, e.g. al_map_rgb() returns an ALLEGRO_COLOR struct which is four floats.
Euphoria currently isn't equipped to pull that off the stack, but it can be. I think we need to work on solving this first instead of relying on hacks or shim libraries.
Most of my time recently has been spent pouring through the source code and picking at things to see how they work.
I will see if I can graft in libffi to replace the existing routines. That should allow a lot more flexibility, broader compatibility, and less work to understand calling conventions, etc.
Another thing we need is a better approach to wrapping C libraries. I've recently revisited IUP and I think I've got a good foundation sketched out for general-purpose C-to-Euphoria wrapping process.
-Greg
Well maybe I'll wait then. Having a libffi in Euphoria would benefit greatly in wrapping C libraries. As would having struct support. A better solution to wrapping libraries sounds great instead of what we currently have. Granted though that Allegro is pretty C-ish and wouldn't be too hard to wrap, except for some routines. But if a better solution is on the horizon, then that sounds great.
Speaking of IUP, I was looking at GUI/Widget toolkits the other day. I was heavily looking at enlightenment/EFL. I develop on Windows and EFL is mainly Linux based, though it is possible to build on Windows according to its documentation. I have yet to sucessfully build it on Windows, but with Windows 10/11 having the Linux Subsystem and Windows 10/11 being even more friendly for programmers (Windows 11 lets you run linux graphical programs, but I'm on Win 10 and my hardware doesn't support 11. Granted there are work-arounds for running graphical Linux apps on Win 10 in the Linux Subsystem), it is becoming easier to develop on. I really think if I or someone else can get EFL to build on Windows, I could start working on a wrapper for Eu, it is very C-ish and looks like it would be fairly straight-forward to wrap. I also took a look at the GTK port of Windows, its a little behind the Linux version, but not by much. Though I don't think there would be much use for a GTK wrapper on Windows.
I did try wrapping FCTLK(or whatever its called), using the C port. Due to bad documentation though, it ended up being abandoned. I might go back and revisit it, but chances of that are slim. I really think Greg has some good ideas, adding libffi support, struct support and a better way to wrap C libraries in Eu. It might (key-word might) even be possible to wrap C-Plus-Plus libs in Eu with the updated tools when they become available. I saw Greg wrapped libUI for Eu, but that is for minimal GUI programs. An updated win32lib wouldn't be bad with support for Win 10/11 and such. WxWidgets could be another solution, QT seems to be ahead of wxWidgets at this point, but it would probably be a pain to wrap QT for Eu, also, its CPlusPlus.
I also did a wrapper for IUP, but its based on an old version.
5. Re: Allegro Wrapper?
- Posted by petelomax Sep 17, 2022
- 1151 views
I also took a look at the GTK port of Windows, its a little behind the Linux version, but not by much. Though I don't think there would be much use for a GTK wrapper on Windows.
One thing I am (idly) contemplating is a new cross-platform gui:
- On Windows it would target winAPI, as per Arwen (but 32 and 64 bit)
- On Linux it would target GTK (and assume .so are already installed)
- For compatibility with p2js, it would use a box model for layout.
Obviously that's a pretty big ask, and I'm still trying to cobble together a flexbox-compatible proof of concept,
in other words resizing a window automatically "space-evenly"'s the contents, expanded to 100% width/height,
and it would target only a fairly specific subset of that CSS functionality, with no attempt to use/implement CSS.
I only mention it because a winAPI/GTK toggle on Windows is a bit of a must-have for testing and development purposes.
6. Re: Allegro Wrapper?
- Posted by Icy_Viking Sep 17, 2022
- 1147 views
I also took a look at the GTK port of Windows, its a little behind the Linux version, but not by much. Though I don't think there would be much use for a GTK wrapper on Windows.
One thing I am (idly) contemplating is a new cross-platform gui:
- On Windows it would target winAPI, as per Arwen (but 32 and 64 bit)
- On Linux it would target GTK (and assume .so are already installed)
- For compatibility with p2js, it would use a box model for layout.
Obviously that's a pretty big ask, and I'm still trying to cobble together a flexbox-compatible proof of concept,
in other words resizing a window automatically "space-evenly"'s the contents, expanded to 100% width/height,
and it would target only a fairly specific subset of that CSS functionality, with no attempt to use/implement CSS.
I only mention it because a winAPI/GTK toggle on Windows is a bit of a must-have for testing and development purposes.
Well I think an overhaul of the win32lib for newer versions of Windows would be great. I may wrap or attempt to wrap GTK for Windows if I get super bored. I've been itching to work on another Euphoria project.
7. Re: Allegro Wrapper?
- Posted by ghaberek (admin) Sep 18, 2022
- 1110 views
Well maybe I'll wait then. Having a libffi in Euphoria would benefit greatly in wrapping C libraries. As would having struct support. A better solution to wrapping libraries sounds great instead of what we currently have. Granted though that Allegro is pretty C-ish and wouldn't be too hard to wrap, except for some routines. But if a better solution is on the horizon, then that sounds great.
It might be possible to wrap libffi and then use it as replacement for std/dll.e today, albeit with an external libffi.dll/so floating around. That might be a good way to sketch out the required changes before diving into making changes in the backend.
Speaking of IUP, I was looking at GUI/Widget toolkits the other day. I was heavily looking at enlightenment/EFL. I develop on Windows and EFL is mainly Linux based, though it is possible to build on Windows according to its documentation. I have yet to sucessfully build it on Windows, but with Windows 10/11 having the Linux Subsystem and Windows 10/11 being even more friendly for programmers (Windows 11 lets you run linux graphical programs, but I'm on Win 10 and my hardware doesn't support 11. Granted there are work-arounds for running graphical Linux apps on Win 10 in the Linux Subsystem), it is becoming easier to develop on. I really think if I or someone else can get EFL to build on Windows, I could start working on a wrapper for Eu, it is very C-ish and looks like it would be fairly straight-forward to wrap. I also took a look at the GTK port of Windows, its a little behind the Linux version, but not by much. Though I don't think there would be much use for a GTK wrapper on Windows.
EFL, like GTK, is one of those libraries where you have to pretty much build your application around all of their core concepts. Their message loop, their object types, their data structures, etc. You're not building "a Euphoria application with EFL interface" you're building "an EFL application using Euphoria" and that's an inversion of principles I'm not too fond of.
I have also been doing almost all of my development in WSL on Windows 10 and it's been working great! I've been testing with IUP, and I'll mount \\wsl$\Ubuntu to a network drive (W:) so I can get to it from command prompt and I can run things from there (with the DLL files in my C:\Euphoria\bin directory).
I did try wrapping FCTLK(or whatever its called), using the C port. Due to bad documentation though, it ended up being abandoned. I might go back and revisit it, but chances of that are slim.
CFLTK is the C wrapper for FLTK the Fast Light Tool Kit, or "fulltick" which itself is a C++ library. It's neat but has a limited selection of widgets compared to most other tool kits.
I really think Greg has some good ideas
Thanks, me too!
adding libffi support, struct support and a better way to wrap C libraries in Eu. It might (key-word might) even be possible to wrap C-Plus-Plus libs in Eu with the updated tools when they become available.
Wrapping C++ directly is possible as long as the ABI is well known and decipherable. AFAIK Matt's original wxEuphoria library did this but he scrapped it in favor of a C shim layer. My approach to wxEuphoria has been a bit of a hybrid between the two: it's still a C shim layer but that layer is built directly into the C++ libraries instead its own dedicated library. Hypothetically it could be turned into a generic C wrapper to replace the ages-old wxC library.
I saw Greg wrapped libUI for Eu, but that is for minimal GUI programs. An updated win32lib wouldn't be bad with support for Win 10/11 and such.
The original libui was practically abandoned by its original author but a group of developers forked it to libui-ng. It's still not ready for regular use but I'm keeping an eye on it. It's still pretty light on features.
WxWidgets could be another solution, QT seems to be ahead of wxWidgets at this point, but it would probably be a pain to wrap QT for Eu, also, its CPlusPlus.
wxWidgets has a much smaller dev team and a much slower release cycle than QT. It also aims for better long-term support and compatibility while QT's gone whole-hog into web-based desktop apps, for better or worse.
FYI if you include a tilde in between the "C" and "++" (like this: C~++) it won't parse it as the "addition" (underline) formatting.
I also did a wrapper for IUP, but its based on an old version.
My latest efforts have resulted in a Makefile and wrapper script that: 1) downloads IUP/CD/IM, 2) extracts the relevant headers and binaries, 3) builds and tests the wrappers, and 4) creates zip packages for each platform. It's almost done!
-Greg
8. Re: Allegro Wrapper?
- Posted by ghaberek (admin) Sep 18, 2022
- 1093 views
Well I think an overhaul of the win32lib for newer versions of Windows would be great. I may wrap or attempt to wrap GTK for Windows if I get super bored. I've been itching to work on another Euphoria project.
I think you're on the right track here. Ideally, the best GUI toolkit for Euphoria is something that is an abstraction of the native platforms. I don't think it'd be terribly difficult to build out a cross-platform Win32Lib-like library today, but I think moving to a proper object-oriented design with actual classes would be a lot better, whenever we get that implemented.
Right now I'm stuck in this Catch-22 chicken-and-the-egg scenario where I need better tools to visualize the Euphoria source code, intermediate language, and symbol table to better understand how everything works, so that I can get features like memstruct finished and start working on classes and several other things. This is what leads me back to IUP, so I can build a dedicated code debugger/object visualizer for Euphoria. It practically going to be an IDE but I won't call it that yet.
-Greg
9. Re: Allegro Wrapper?
- Posted by Icy_Viking Sep 18, 2022
- 1079 views
Well I think an overhaul of the win32lib for newer versions of Windows would be great. I may wrap or attempt to wrap GTK for Windows if I get super bored. I've been itching to work on another Euphoria project.
I think you're on the right track here. Ideally, the best GUI toolkit for Euphoria is something that is an abstraction of the native platforms. I don't think it'd be terribly difficult to build out a cross-platform Win32Lib-like library today, but I think moving to a proper object-oriented design with actual classes would be a lot better, whenever we get that implemented.
Right now I'm stuck in this Catch-22 chicken-and-the-egg scenario where I need better tools to visualize the Euphoria source code, intermediate language, and symbol table to better understand how everything works, so that I can get features like memstruct finished and start working on classes and several other things. This is what leads me back to IUP, so I can build a dedicated code debugger/object visualizer for Euphoria. It practically going to be an IDE but I won't call it that yet.
-Greg
Well I could wrap IUP for the most current version. Though it sounds like you already have an IUP wrapper in the works. AS I said eariler I might wrap or try to wrap the Windows build of GTK if I get super bored. It should be cross-platform. If its possible to wrap C++ libraries, wrapping ClanLib would be something I'd look into.
10. Re: Allegro Wrapper?
- Posted by petelomax Sep 21, 2022
- 993 views
Right now ... I need better tools to visualize the Euphoria source code, intermediate language, and symbol table to better understand how everything works,
Indeed, having a visual display of the parse tree proved very helpful when writing the transpiler, and to a lesser/shorter term extent the token list.
It was not particularly difficult either, while this is phix and in fact p2js-specific, the main bit of code ended up being just
elsif what="PARSETREE" then sequence tree_nodes = treeify(ast) if tree_dlg=NULL then tree = IupTreeView(tree_nodes) IupSetCallback(tree, "SELECTION_CB", Icallback("selection_cb")) tree_dlg = IupDialog(tree) IupSetAttributeHandle(tree_dlg,"PARENTDIALOG",main_dlg) IupSetAttribute(tree_dlg,"TITLE","Parse Tree") IupSetAttribute(tree_dlg,"RASTERSIZE","660x830") IupSetCallback(tree_dlg, "CLOSE_CB", Icallback("close_sub_cb")) else IupTreeAddNodes(tree,tree_nodes) end if IupConfigDialogShow(config, tree_dlg, "ParseTree")
The treeify() function is a fairly trivial (and very p2js-specific) munging into a more consistent structure, and
IupTreeView()/IupTreeAddNodes() were specially written for phix, but probably quite nickable.
From further back in time, ildump.txt and list.asm contain the intermediate code and symbol table respectively,
and it probably would be nicer if they could be displayed/filtered on-screen, rather than being flat text files.
11. Re: Allegro Wrapper?
- Posted by ChrisB (moderator) Sep 24, 2022
- 869 views
Hello all,
So recently after looking through the updated documentation of Allegro, I have thought about making an Allegro wrapper. Now I know I did in the past, but its old and the codebase is just ugh. So I would rather start new with the most recent version of Allegro. Just wondering if anyone would use it or have use for it?
Codebase wise it would be similar to how the C version is. Each would have its own .e include file. For example: base.h would base.e and would contain the Euphoria code equvialent for wrapping DLLs.
So, quite a whie ago I created quite a substantial wiki entry for Allegro 4.2, with a game demo, which tailed off. If anyone's interested allegro is a very capable game dev library for allegro.
https://openeuphoria.org/wiki/view/allegro.wc
Cheers
Chris
12. Re: Allegro Wrapper?
- Posted by Icy_Viking Oct 09, 2022
- 789 views
Alright so now that FFI has been implemented, even if it is external for right now. I think I will tackle making an Allegro wrapper for the current Allegro 5 version.
13. Re: Allegro Wrapper?
- Posted by mitgedanken Oct 10, 2022
- 743 views
[...] Ideally, the best GUI toolkit [...] is an abstraction of the native platforms. [..] Win32Lib-like library today, but I think moving to a proper object-oriented design with actual classes would be a lot better, whenever we get that implemented. [...]
-Greg
There is Wing. Maybe helpful?!
Wing is a library which provides GLib-like API to some Windows API.
