C language > Graphics programming
Nuklear immediate mode GUI - C and small
Scripter:
--- Quote from: Eggy on July 31, 2016, 08:44:02 AM ---Scripter,
Good to hear we come from the same dynasty!
--- End quote ---
Sometimes I think I've been at this too long. But then some interesting project pops up and grabs my attention and off I go again.
Some of my pre-PC computers...
http://www.old-computers.com/museum/computer.asp?st=1&c=214
http://www.old-computers.com/museum/computer.asp?st=1&c=204
http://www.old-computers.com/museum/computer.asp?c=210&st=1
--- Quote ---Your comments and opinions are valued to me, since I am operating in a vacuum here right now. I too would stay with just one platform or the other, but I run Linux and Windows for work and pleasure, so I am in that world ;)
--- End quote ---
Edit: Wine on Linux?
I've been there too. At one time I was determined to "learn it all". Maybe it's age talking or maybe it's just too much for any one person but someplace along the way I decided to stay strictly with Windows and, despite repeated trials of other compilers, with Pelles C. I still puzzle over whether I'm in a rut or I've simply found the right tool for the work I do...
--- Quote ---Also, for game jams, you up your exposure by providing it on many platforms, which is why HTML5 games are so popular there, and Love2D, a Lua-based game framework that runs on everything. There are 3D engines like Godot too, but like you, I want to program close to the machine with the caveat of using a GUI library, since there is no penalty in rendering. I do think the higher-level libs are too much abstraction, and I agree they make it harder than just dropping down and coding it natively. But for sound, graphics, i/o, it is hard to beat SDL2. It is not too far from the ground or gold as you say.
--- End quote ---
SDL is a better tool than DirectX ... but then my grandkid's etch-a-sketch is better than DirectX.
Over the years, in many hundreds of emails with a friend who works in IT, we have lamented the powerful stupidity of ActiveX, DirectX, COM and other pointlessly complicated inventions that are supposed to make things better while simultaneously frying the brains of otherwise competent programmers. Whatever possessed Microsoft to use OOP in core level functionality is one of the grand mysteries of our time.
--- Quote ---You have inspired me to do a little test. I will create a minimal game with a window, sound and logic:
1. Windows target w/ Pelles C, and the Win32 API for GUI (Wn32 native sound API?? for game dev? Or, do I need something like S?)
2. Linux target w/ GCC, and I should try to use X11 to make it a fair comparison, although I may use Gnome.
If I still have questions and time, I will try and do the same tests above using SDL2 or CSFML for both tests and compare again.
--- End quote ---
If you truly do need/want to issue multi-platform code this will be little more than a side trip but it would be very interesting to see what you come up with.
My original suggestion that you should equip yourself with the SDK still stands. You actually only need the documentation. Pelles comes with it's own version of the libs and headers and, as you will see in other threads, it does not work at all well with the ones Microsoft provides. So most of what you need is already on your system. But, even if you are using primarily high level libraries for your work there will still be occasions where you will need to delve into the guts of Windows to get what you want. It will be to your advantage to know enough of the SDK and GUI mode programming to be able to do that when necessary.
But I should be honest here and tell you that Pelles C may not be the best tool for the type of coding you are describing. Pelles big strength is in console mode or smaller control/dialog based GUI projects... the kind of stuff I write. I would never consider writing (for example) a multimedia player in Pelles C. To truly use the OOP constructs needed for graphics and sound in Windows (except at the most primitive levels) you really do need to be on C++.
You may find this interesting... http://orwelldevcpp.blogspot.ca ... this is a continuation of the old DEVCPP project using GCC and it's derivatives. I've tried it out, seems ok, but it's not the best tool for what I do so that was only a trial. GCC lacks exception handling --try-except and try-finally-- which is a necessity in the kind of work I've been doing for the past couple of years.
Still, the experience should be very educational and I will be interested to see your results.
Scripter:
--- Quote from: frankie on July 30, 2016, 09:38:04 PM ---Maybe, but some comments make me think that is not a translation, but just a trial to write Ansi-C from a C++ background...
--- End quote ---
Ok, that makes sense ... thanks.
Eggy:
Me too!
This was my first, and I am tempted to buy one in supposed working order.
http://www.old-computers.com/museum/computer.asp?st=1&c=191#ebay
I also owned a Vic-20, Amiga 1000, Amiga 500 and then a slew of PCs. I had an NCR 3125 3086 pen-based tablet computer in 1996!
--- Quote ---Edit: Wine on Linux?
I've been there too. At one time I was determined to "learn it all". Maybe it's age talking or maybe it's just too much for any one person but someplace along the way I decided to stay strictly with Windows and, despite repeated trials of other compilers, with Pelles C. I still puzzle over whether I'm in a rut or I've simply found the right tool for the work I do...
--- End quote ---
[Edit]
No, I know when I am in over my head. That is why finding Pelles C was so fortuitous.
I am resolved to stay minimal with languages like C and J. It is the reason I wrote 8-bit chip programs in C and Forth years ago, and thoroughly enjoyed it.
The J programming language reminds me of those early years. You can do so much in the interpreter/REPL - graphics, plots, high-level math all in a very terse syntax. It is the one language that has remained most constant aside from C, and not just as a desktop calculator. Some really serious companies and programmers use it like the ones that use qdb/k.
I am forced to use Python, Lua and JavaScript at times, just because they are the only thing made available to me.
Most of my paid programming background was writing data munging or cleanup programs in the 90s, and some DBA work in the early 2000s. Nowadays, I pretty much code toys for myself to further my personal studies into mathematics, art, music, etc... and have great fun!
I am resolved to master J and stay with C, no C++, too big and unsuitable for my tasks (well, not the games, but for the minimal games, yes). And, I never really bought into the OOP thing. I have put aside Haskell, F#, and others until I make at least 100 more things in J and C. I am now just looking at hooking into J via C and C with J.
--- Quote ---My original suggestion that you should equip yourself with the SDK still stands. You actually only need the documentation. Pelles comes with it's own version of the libs and headers and, as you will see in other threads, it does not work at all well with the ones Microsoft provides. So most of what you need is already on your system. But, even if you are using primarily high level libraries for your work there will still be occasions where you will need to delve into the guts of Windows to get what you want. It will be to your advantage to know enough of the SDK and GUI mode programming to be able to do that when necessary.
--- End quote ---
[Edit]
I have already started on them, thanks! I have to say, though, I now remember why I gave up any Win32 API GUI stuff with C and Windows: I dislike the verbosity and cryptic or non-ideal names for things. As big as some of the other libs are, they use sensible names without all caps and other such obfuscation and aesthetics. It does produce the best Windows on Windows though, and it is just personal taste, not mechanics. It's coming back to me each day...oh, the horror ;)
BTW, stubborn Googling led me to this perfect example of an immediate-mode GUI for what I need.
http://anttweakbar.sourceforge.net/doc/
Development has stopped, but it works wonderfully as is, has plenty of examples to show it with different libs, SDL included. I only have to get SDL2.0 working with it, and just use it and C!
I am having a hard time figuring out where to link, and include things in Pelles C. The fields are there sure, but I am used to command line links, and just relying on <include>s in my source. Since people who do game jams usually bundle everything for distro to ensure everyone can try it to judge it, I am putting the necessary files in my Pelles C project directory, adding them to the 'Folders' and 'Linker' tabs.
Thanks!
Rob
Scripter:
--- Quote from: Eggy on August 01, 2016, 11:54:14 AM ---No, I know when I am in over my head. That is why finding Pelles C was so fortuitous.
I am resolved to stay minimal with languages like C and J. It is the reason I wrote 8-bit chip programs in C and Forth years ago, and thoroughly enjoyed it.
--- End quote ---
I mainly ran the BASIC, Turbo BASIC, Turbo Pascal, C route, like probably most people getting into this back then did. Unfortunately, in this day and age programs are not that simple anymore. Now you need manifests, resources, exception handlers, code signers, installers, and on and on if you are to produce anything more than a cute guessing game for your kids.
--- Quote ---The J programming language reminds me of those early years. You can do so much in the interpreter/REPL - graphics, plots, high-level math all in a very terse syntax. It is the one language that has remained most constant aside from C, and not just as a desktop calculator. Some really serious companies and programmers use it like the ones that use qdb/k.
--- End quote ---
I had to look J up ... interesting.
--- Quote ---I am forced to use Python, Lua and JavaScript at times, just because they are the only thing made available to me.
Most of my paid programming background was writing data munging or cleanup programs in the 90s, and some DBA work in the early 2000s. Nowadays, I pretty much code toys for myself to further my personal studies into mathematics, art, music, etc... and have great fun!
--- End quote ---
My "pro" work (which actually subsisted with a service manager's job) was primarily concentrated on diagnostics and simple utilities. This is where I got the "really tiny program" thing from and I think it's actually an interesting area to play in. As one member of a Pascal forum once said after seeing an early version of my FSVerify tool: "You don't just write small programs, you write small small programs". ;)
--- Quote ---I am resolved to master J and stay with C, no C++, too big and unsuitable for my tasks (well, not the games, but for the minimal games, yes). And, I never really bought into the OOP thing. I have put aside Haskell, F#, and others until I make at least 100 more things in J and C. I am now just looking at hooking into J via C and C with J.
--- End quote ---
I don't even want to guess how many times I've tried C++ and OOP code only to eventually find my way back to the basic languages like C or Pascal. Of course Pascal is now a dead language with almost no worthwhile development happening at all... otherwise I'd still be there. Pascal uses a very C-like syntax but produces much "safer" code since everything is bounds and overflow checked... which C doesn't even know how to do.
--- Quote ---
--- Quote ---My original suggestion that you should equip yourself with the SDK still stands.
--- End quote ---
I have already started on them, thanks! I have to say, though, I now remember why I gave up any Win32 API GUI stuff with C and Windows: I dislike the verbosity and cryptic or non-ideal names for things. As big as some of the other libs are, they use sensible names without all caps and other such obfuscation and aesthetics. It does produce the best Windows on Windows though, and it is just personal taste, not mechanics. It's coming back to me each day...oh, the horror ;)
--- End quote ---
Microsoft has a "naming convention" for their SDK code and once you get used to it, it does make sense and it does provide some "instant recognition" to your code. For example when you see something like WIN32_FIND_DATA you know it's a struct or when you see CopyFile you know it's a function call. and so on..
It just takes some getting used to.
--- Quote ---I am having a hard time figuring out where to link, and include things in Pelles C. The fields are there sure, but I am used to command line links, and just relying on <include>s in my source. Since people who do game jams usually bundle everything for distro to ensure everyone can try it to judge it, I am putting the necessary files in my Pelles C project directory, adding them to the 'Folders' and 'Linker' tabs.
--- End quote ---
If you install the WSEdit3 addin from the link I gave you, you will see that I've solved that problem for you. Pelles C includes a define (#define WIN32_DEFAULT_LIBS) that will auto-include the correct libraries when adding headers with #include. When you create projects and workspaces with WSEdit the define is already hooked into your program settings...
Alternatively you can use pragmas in to include individual libraries. There are two ways to do that...
--- Code: ---#pragma lib <library name>
or
#pragma comment(lib, <library name>)
--- End code ---
Both are described in the help file in the command line tools/pocc section. The first one is Pelles specific the second (ugly) version is more generic.
If you are looking for examples... this is from the top of one of the files in my Renamer project...
--- Code: ---// the rename algorithm
#include "..\renamer.h"
// include library in search path
#ifdef _WIN64
#pragma comment(lib, "..\\ren64.lib")
#else
#pragma comment(lib, "..\\ren32.lib")
#endif
--- End code ---
Also, if you are incorporating third party libs, you can modify your search paths in the Project Settings->Folders tab to include the relevant folders. This is better than creating dozens of duplicates in your project folders.
Navigation
[0] Message Index
[*] Previous page
Go to full version