#bongocat-plus
1 messages · Page 1 of 1 (latest)
Currently working on a window resizing bug
Where resizing the window will mess with the sprite rendering and will create artifacts
Fixed by storing the render states then drawing the sprites accordingly
You can also now resize the actual window and it will adjust accordingly.
I am now going to start working on this issue: https://github.com/ZackeryRSmith/bongocat-osu/issues/2
Whoops small issue with the OSU cat, the right hand doesn't actually apply the new height correctly
Fixed
Feature has been added
Thickness is now changable via the config by doing
"pawArc1Width": int1,
"pawArc2Width": int2
I'm going to attempt to add this https://github.com/ZackeryRSmith/bongocat-osu/issues/11
😼
God I forget I3 doesn't really support transparent windows
Time to switch to a desktop enviroment for a bit
maaynnn, I don't think there is a way to do this in SFML without using like the windows api to do it
Which well works for windows but not linux :/
Well I guess I already use the Windows api and X11
I'll just use em for the transparency
Well it's kind of possible
Seems like I have implemented something wrong
Putting this to the side for now
As SFML doesn't support transparency I have to do this with the WinAPI (windows) and X11 (linux)
It'll be quite a bit of work to implement
So I'll put it off to the side till more features are done
Yeahhh
I may not support transparent window for a bit
Though on OBS keying is the best option.
But actually supporting transparency on the window is pretty hard
Now working on https://github.com/ZackeryRSmith/bongocat-osu/issues/7
I'll probably implement this by allowing key1 and key2 to take a list rather than a single value. I was originally thinking of having a bool like anyKey but I've decided against that for a few reasons.
Done
Anything that takes a key input can be mapped to multiple keys
@kindred plover would you be able to test this project with WSL?
Sorry for asking
Just want to know if key capturing works on windows even though WSL
Yeah one second
I had @unique scaffold test it
It has some issues 😳
WSL and X11 do not work well together
Yeah it's because you need xdotools
sudo apt install xdotool
And such
But yeah, I should convert it to an appimage
so you don't need to install libraries
I kind of forgot to implement changing the width in the config.
done
Now working on https://github.com/ZackeryRSmith/bongocat-osu/issues/19
In the config ASCII key codes are used, when really it should just be an ASCII character
This would make life a lot better for whoever is modifying the config, so they don't have to search key codes up and such.
"key1": [90] ← current config style
"key1": ["x"] ← what the config would look like
Whoop got distracted
Feature added
Along with making sure the string is only 1 character long
It doesn't throw an error but rather only grabs the first character
so "key1": ["xyz"] would only grab x
Maybe I should throw a syntax error if the string is greater than one character?
Dunno
I'll just leave it as is for now
It also only supports using a char now
You can't use numeric values. Should I allow both?
I wonder, I'll sleep on it I guess.
I'm going to add this
Because I just remembered some keys are impossible to easily represent as a string
take the arrow keys for example
Now supports both chars and char codes in one list
It makes something like this possible "key1": ["Z", 65, "C"]
Which is equal to "key1": ["Z", "A", "C"],
This is what the current config looks like
Ofc you can add more cats to the config, which will check /cats/ to see if that cat exists. If the cat exists and is selected it will be initialized and then drawn.
Closed.
I'll probably work on this tomorrow
I am quite tired
This is another one I'll do https://github.com/ZackeryRSmith/bongocat-osu/issues/6
I'm also going to try to tackle https://github.com/ZackeryRSmith/bongocat-osu/issues/12
For now to make like easier instead of allowing backgroundColor to be either a list or a string I've opted to just keep it a list no matter the case. Whether a hex or 4 values are being used.
This is because I have code which makes sure config.json types are valid before actually allowing anything else to run
bool update(Json::Value &cfg_default, Json::Value &cfg) {
bool is_update = true;
for (const auto &key : cfg.getMemberNames()) {
if (cfg_default.isMember(key)) {
if (cfg_default[key].type() != cfg[key].type()) {
error_msg("Value type error in config.json", "Error reading configs");
return false;
}
if (cfg_default[key].isArray() && !cfg_default[key].empty()) {
for (Json::Value &v : cfg[key]) {
if (v.type() != cfg_default[key][0].type()) {
error_msg("Value type in array error in config.json", "Error reading configs");
return false;
}
}
}
if (cfg_default[key].isObject()) {
is_update &= update(cfg_default[key], cfg[key]);
} else {
cfg_default[key] = cfg[key];
}
} else {
cfg_default[key] = cfg[key];
}
}
return is_update;
}
I could hard code a rule like
if (key == "backgroundColor") {
continue;
}
```But I really don't want to do this
I plan on expanding this project quite a lot
Maybe even past Bongocat, so I'd like to keep that in mind
I also would like this program to be as modular as I can without too many headaches
So for now I'll keep this weird syntax, which I will be fixing tomorrow morning
This checking system is getting on my nerves just a bit
I'm disabling it for now and I'll add it back once I'm satisfied with the config structure as a whole
This is probably the better idea, as I can develop freely then childproof later
Annnnndddd I'm just giving up on this issue
It's not that big of a deal to implement, but SFML doesn't take your conventional hex. Anyway, I'll get around to it later
closed.
I’ve been at my grandmas for a while, she doesn’t have Wi-Fi nor do I have my laptop with me. I’m not sure if I’ll get much done today
Phone programming time
Ah damn
I'm going to write some code which helps facilitate the development of the cats code.
Added wrapper function for input::is_pressed(), which can be accessed likes helpers::is_pressed()
This cleans some repeating code
I'd like to write a helper function for loading keybinds, and checking for duplicates.
I'll probably just use templating, as I'm not sure how many key states the user takes in inputs for
Or I could just do the normal way of taking multiple values
Done.
This is the new code for checking overlapping keys
// check for overlapping keybinds
if (helpers::keys_overlapping({left_key_value, right_key_value, wave_key_value, smoke_key_value})) {
data::error_msg("Overlapping osu! keybinds", "Error reading configs");
return false;
}
```This code is also modular like I wanted it to be
You can add more keys to be checked and everything will work fine
This is cleaner then the old method which looks like:
bool chk[256];
std::fill(chk, chk + 256, false);
/* key1 & key2 */
if (!use_any_key) {
left_key_value = osu["key1"];
for (Json::Value &v : left_key_value) {
chk[v.asInt()] = true;
}
right_key_value = osu["key2"];
for (Json::Value &v : right_key_value) {
if (chk[v.asInt()]) {
data::error_msg("Overlapping osu! keybinds", "Error reading configs");
return false;
}
}
}
/* wave */
wave_key_value = osu["wave"];
for (Json::Value &v : wave_key_value) {
if (chk[v.asInt()]) {
data::error_msg("Overlapping osu! keybinds", "Error reading configs");
return false;
}
}
/* smoke */
smoke_key_value = osu["smoke"];
for (Json::Value &v : smoke_key_value) {
if (chk[v.asInt()]) {
data::error_msg("Overlapping osu! keybinds", "Error reading configs");
return false;
}
}
Here is the code for helpers::keys_overlapping()
// Code cleaner. Makes checking for overlapping keys a breeze
// * Automaticly converts ASCII chars to ASCII codes
bool keys_overlapping(std::vector<Json::Value> key_arrays) {
bool chk[256]{}; // check buffer, used to keep track of keys
int v;
for (Json::Value &key_array : key_arrays) {
for (Json::Value &tmp : key_array) {
v = tmp.isInt() ? tmp.asInt() : (int)tmp.asString().at(0);
if (chk[v]) { return true; }
chk[v] = true;
}
}
return false;
}
Just pushed the changes I've made over these few days :)
Been working on switching the project from working with a bunch of namespaces, to a few namespaces and a few classes
Much more managable
Still not done, it's been giving me trouble for hours now
Ok, holy
That was a fun time
now classes are pretty much fully implemented
All that's required when adding a new cat is including the cat's logic file and adding a new case to the switch statment
Working on fixing this
Not passing the render states seems to fix the issue, well somewhat.
I still need to render things keeping render states in mind, so visual bugs are kept to a minimum
It all works fine width wise.
Only issue is the background is locked to the top of the window, not the bottom like it should be
Setting the proper height makes everything fine though (I also set the width back to the proper size)
Just pushed some commits!
bongocat-plus
I probably won't be working much on the project until next Tuesday. Which is when my midterm ends
Working on adding lua scripting support
Would you mind explaining what's bongocat
I see it's an overlay but what does it do
Bongocat was originally just some meme website someone made. Bongocat then became popular for people who didn't want a face cam but wanted something in its place. Bongocat-plus aims to hopefully be the "best" bongocat overlay supporting some extensible scripting for each cat overlay. The project in which Bongocat-plus was orginally forked from is Bongocat-osu. Osu is a rhythm game, with 4 different modes.
Anyway all it is, is a cute overlay for games
Working on proper MacOSX support
Switched to a more modern build system; cmake.
Cmake also displays some nice information about the build, which can be very helpful for debugging
There is an issue with capturing mouse input on MacOSX
As MacOSX uses a Quartz display server, many features in XDOTOOL don't actually work as expected
Fixed some MacOSX bugs
Biggest one being mouse tracking
You can now make bongocat borderless
You can still drag the application in borderless mode. Just grab ahold of anywhere on the app and drag
Found a new bug with onboard config reloading
@mental fossil HES ALIVE
It is 😛
Yep :)
Still not going to be as active for a while but I'll poke my head in every afternoon
It's nice to see you at least
Thanks, I do miss helping out here
Well hopefully you can help out a lot more soon
Removed the numerous dependencies that were being compiled alongside Mac which are only for Linux. Apparently CMake doesn't have a built in way to distinguish MacOSX or Linux, they are under the same group Unix.
Either way, fixed
Nice
Working on implementing support for miniaudio, I will be building off miniaudio to make a higher level api for interfacing with the mic. This feature was inspired by https://github.com/ZackeryRSmith/bongocat-plus/issues/6
Miniaudio deals with a lot of the pain for me, I get the easy bit of making the miniaudio a bit more user friendly
Whoops I'm dumb
SFML supports this kind of stuff already
I don't need to even mess with miniaudio
:P
When I'll head home I'm gonna try this out
I barely tested Windows, though it hopefully should work. I'm not very good with the Windows api :P
Worth a shot though
Alright I'm going to try and compile Bongocat-Plus for windows
We'll see how it goes
Worked first try, 100% :)
I will update cmake
I already have the most up-to-date visual studio C++ redistributable
I'm not going to mess with it too much, don't have a lot of time to mess with this. I have to study for some upcoming tests
but the issue seems to be somewhat easy to fix (based on some stackoverflow solutions)
We'll see when I come back to this
The linux build should work fine too
I did change the code quite a bit though, but I know my way around x11 enough to where I can confidently say the code should work.
I changed a lot of mouse handling code so I'm scared that it won't compile
we'll see though, i'll try to build it in a bit
can you send the executable here, it didn't work for me :/
Yeah I couldn't get the executable to compile either, not an issue with the code so far though. Cmake can't find my cxx compiler. I'll mess with it and try to get an executable to you
bongocat-plus is now able to be compiled on Windows with ease.
Without the need for installing SFML manually
I'm marking the Windows build in the readme as passing
nice
the readme build instructions are not up-to-date, and may not be for a little while
Yippieeee
3 hours of my life though
To get a working build, and make it easy to compile
:(
The cats mouse will now size down to whatever is the focused window, this behavior isn't currently toggleable but will be in the near future
This should work fine
two months later he compiled it
Sorrrryryyyy
lmfao
Well it's compiled now B)
lmao
@mental fossil is the current repo stable on linux?
It shoulddd be, but I don't have a linux machine rn to test it on
Go for it
:)
also will point out this is a windows build and probably won't work on Mac, or Linux without recompiling
Nice
Make it so the console is hidden on Windows
Yeah I don't even know why that's there
¯_(ツ)_/¯
Use int WINAPI WinMain() instead of int main()
Weird
Add FreeConsole() to the beginning of the program
Not the best option because it is still running with the console subsystem but it hides the console
Yeah that hides it
Shows up then gets hidden
#if defined(__unix__) || defined(__unix) || __APPLE__
int main(int argc, char ** argv) {
#else
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
FreeConsole();
#endif
Will the console at least terminate when the program is exited?
👍
Fixed #24 #25 and #29
🥳 🎉 BONGOCAT-PLUS IS WORKING ON ALL MAJOR PLATFORMS 🎉🥳
(Windows, MacOSX, and Linux)
Yippeee
for how long though 🤨
Thanks @unique scaffold for helping out with the Linux testing and support :)
🎉
Created new branch for Lua scripting support
The CMake is now actually maintainable
MacOSX and Linux are now no longer forced to have SFML built and compiled if SFML is already installed on the system
So far I've only setup the CMake to download lua, compile it, and link it. Working on the actual scripting support now
What would be the Lua support for?
For having custom cat logic files be external instead of being compiled with the application like it is now
I would like the cat logic files to be external instead of compiled with the application because it would make sharing cats, and modifing them much easier
ah
Going through a refactor throwing all the code out the window
I've been doing the refactor for about 2 days now, and lua support is now actually viable. Using LuaBridge3 to bind needed parts of the SFML library
The code structure is now much more modular, and comprehensible.
Window management is no longer done by the user in lua, as the c++ backend now handles all the underlying SFML code.
The user is only exposed the required SFML types and classes that are required. Like sprites, images, and etc. Along with some types like Vector2<T>
Only one window is given to the user, and no more can be created by a user. This could be seen as limiting but I currently don't have a good way of allowing a user to manage their own windows and have it be memory safe. Along with that, who even needs more then one window... unless you're trying to be cool. You don't need it
Along with that audio will now be possible using SFML and it's audio system
Proper input handling is still hell, so as such I'll write some helpers and expose them to lua
I have also created a stubs.lua file for helping IDEs or linting tools understand the skeletal representation of the BongoCat Lua API
I have also changed the cmake a lot, now it's much more readable
Many of the features listed above are still being worked on, but the current refactor can be found here
Shortly I will be pushing many changes
TL;DR
I'm refactoring bongocat-plus, thus removing much of the weird code caused by a 5 year old unmaintained project started by kuroni. With Lua support at the forefront of development. Windows, MacOSX, and Linux are still tested and all will still function
Cleaned up sprite rendering and loading
Now instead of manually loading an image as a texture, check for errors, then converting it to a sprite, can now be done as```lua
local spritename = BongoSprite.loadFromFile("image path")
Managing a window is no longer up to the lua script
This may strip some power from the user, as now only one window can be created at a time, and it's all managed by the c++ backend
You can, however interact with the window using BongoWindow. Like for example clearing the screen with a color, and you may choose when to display your sprites
This is all you need, at least it's anything I've ever needed.
-- load a sprite
local sprite = BongoSprite.loadFromFile("sprite.png")
-- create a window
BongoWindow.create(612, 354, Sfml.Style.Default)
while BongoWindow.processEvents() == 0 do
-- clear the window with a color (optional but recommended)
BongoWindow.clear(Sfml.Color.White)
-- draw some sprite to the window
BongoWindow.draw(sprite)
-- display the window's contents
BongoWindow.display()
end
This is basic boilerplate for loading a sprite and displaying it
compared to the old way
-- create a window
BongoWindow.create(800, 450, Sfml.Style.Default)
-- laad an image into a texture
local texture = Sfml.Texture()
if not texture:loadFromFile("sprite.png", Sfml.IntRect()) then
print("Error loading image")
return
end
-- create a sprite and set it's texture
local sprite = Sfml.Sprite()
sprite:setTexture(texture)
while BongoWindow.processEvents() == 0 do
-- clear the window with a color (optional but recommended)
BongoWindow.clear(Sfml.Color.Black)
-- draw the sprite to the window
BongoWindow.draw(sprite)
-- display the window's contents
BongoWindow.display()
end
Another thing provided to you through BongoWindow, is managing Window events
As you can see in this line```lua
while BongoWindow.processEvents() == 0 do
BongoWindow.processEvents() will return 1 once the window is asked to close
Currently playing with scaling and how to deal with window resizes
This is something I previously ignored, disabling window resizing.
But as I was using i3wm I wasn't limited to the size of window I could spawn as it'd be automatically resized for me. This causes some obvious issues, I want cat's to work across all screen sizes, scaling down or up at a certain aspect ratio
One thing currently being worked on is some simple logging, especially now that a lua frontend is used. If you write some wacky lua that will break things warnings should be in place
Along with the scaling, if it works and looks good on the developers screen, it should scale appropriately on other screens so it looks just how the developer intended.
Added:
Warning if BongoCat+ is unable to spawn a window of a certain size E.g.
BongoCat+ [WARN]: Cannot spawn window of size (612, 1900), window has been sized down to (612, 779)
Added basic input handling
The Lua api now has a simple way to interact with keys and such
The Lua code for doing so looks like```lua
if is_pressed(BongoInput.Key.backspace) then
-- whatever you want here
end
These changes can be seen here
With this addition the Lua api is pretty much done
At least a very basic implementation
I have also updated the stubs.lua file as well to better represent the current state of the bindings
its the monthly update 🎉
lmao, very true
I only work on Bongocat+ when I am bored as it's a easy and fun project to work on in my downtime
how the fuck do you consider this easy
lmao, it truly is. Everything before the rewrite is hell though
i litterally have a project where 80% of it is copy paste, the other 20% is manipulate github copilot and i thought that was hard
Your OS?
Well this is really just a lot of simple repetitive tasks
Like binding to lua
and adding simple features
Oh I remember that
Yeah well... I'd assume
OS dev doesn't sound easy by any means
well that's a problem lol
why do you think i havent touched the project
Also another update to BongoInput is it now supports on_pressed and on_released so you can do something like```lua
if on_pressed(BongoInput.Key.s) then
-- something here
end
True
I would like to try OS Dev but I currently have a lot of projects being worked on
My main one being #1163111883851698266
Although I haven't posted much in the forum the project is by no means dead and has been getting a lot of updates
honestly, i coudl use some help if you want to join me
I wouldn't mind but I'm the type of person to plan projects for jumping into them. I may pick up a read on OS Dev to get a grasp of what it entails
yeah, that is highly nescesary
Yeah... I know ASM to a pretty good degree but I have no clue where to start on an OS
well, because im using a premade bootloader, asm is as heavly needed
If I was making on OS I'd like to avoid using anything premade
Which would be hell
But I'm a programming masochist
LMAO
imma text your gf and ask her
She'd say yes 😭
i gotta see this hold on
You got her on speed dial?
not nescesaryly
Instagram? That's the only platform I could see you having her on
yeah, her account pops up alot because of you being a mutual follower
Ah, makes sense
OS Dev is something I've always wanted to dip my toes in, so I'm very tempted. I definitely will pick up something that I can read in my spare time about it
i dont think i need to say this, but do check out https://wiki.osdev.org not only is it a good resource itself, it links to a lot of others
That would've been the first place I'd look
fuck off @queen robin
Vladhog finds this one spooky
it will be hell
Oh shit, that looks juicy
its a little thicc
honestly though, limine is amazing
with the only exception that it doesnt support vary many filesystems
also, we should move this to #1160349382336589915
Yeah true, flooding my monthy cat updates is hurting my moral 
added drawif function to simplify the need to have an if then for checking variable states
So lua if smoke_state then BongoWindow.draw(smoke) end becomes```lua
BongoWindow.drawif(smoke, smoke_state)
Here is my current testing lua file```lua
--==========================--
-- Just testing lua support --
--==========================--
-- laad our images. LOAD BEFORE CREATING THE WINDOW!
local smoke = BongoSprite.loadFromFile("cats/osu/smoke.png")
local mousebg = BongoSprite.loadFromFile("cats/osu/mousebg.png")
-- states
local smoke_state = false
-- create a window
BongoWindow.create(612, 354)
while BongoWindow.processEvents() == 0 do
-- clear the window with a color (optional but recommended)
BongoWindow.clear(Sfml.Color.White)
-- smoke logic
if on_pressed(BongoInput.Key.s) then
smoke_state = not smoke_state
end
-- draw the sprite to the window
BongoWindow.draw(mousebg)
-- draw smoke if smoke_state is true
BongoWindow.drawif(smoke, smoke_state)
-- display the window's contents
BongoWindow.display()
end
Which results in
Even when not in the app s is still being monitored
These changes have been pushed
Major rework of the whole paw movement
Or well one that's currently underway
As the original code from 5 years ago from Kuvster is just an unreadable atrocity
The only reason it stuck was I didn't want to take time to go through the ugly code and math to understand it well enough to rewrite the code.
After some time working through it I have a solid idea of how everything works, and the general math behind it
I also have an understanding of how I want to structure my c++ code and lua api for working with the paw
i thought you were bad at math
Nothing a wikipedia read can't fix
Fair
The arcs of the hand are calculated in two parts, they're both just bezier curves with a dynamic control point which is based of the mouse position and some magic numbers
Then filling in the hand is just some other math
using SFML's TriangleStrip and a VertexArray makes it a breeze
Well I say that... if you'd like to (try to) read Kuvster's impl. for drawing the paw go ahead and try
Actually I encourage you to try, maybe you'd be able to
were you able to?
Yes
Well breaking it up into parts and racking my brain for a while
I'm just working now on rewriting the logic
and making it more modular, and in-turn more readable
it hurt my head, although, i didnt look at it for very long and i have no clue whats going on soo
Yeah, it's horrible to read. So far my impl. is doing much better on being readable
and more expandable so the lua api has more flexibility over the paw, along with color, line thickness, it's position
and such
i was about to say wtf is suhc
My bad, it's been a long day
understandable
command to build Bongocat+ now vs the old waybash cmake . && make vs```bash
mkdir build
cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cd build && make
Alright welcome me back fro the monthly update, yayyy!!!
Working on going through all the issues
creating new ones and revising old ones
Hand movement stumped me a lot previously
So the best solution... ignore it
I will be implementing the other core parts of Bongocat-Plus before touching it again
Here is a pretty important issue that I want to be known: https://github.com/ZackeryRSmith/bongocat-plus/issues/38
Oh also just a note I got a star from one of the original contributors of Bongocat-OSU the project Bongocat-Plus us based from
Pretty neat
Oh yeah bongo logging in lua? Well here you are
The code for logging is quite straight forward as you'd imagine
bongoDebug("Where are the bugs?")
bongoError("Oh not this again...")
bongoFatal("OH GOD I'M PANICKING!!")
bongoInfo("phew, fixed")
bongoWarn("... shit")
To allow the mouse support that I mentioned I wanted in a closed issue (#32)
To do this I will have to rewrite the entire mouse capturing system
The mouse hand also isn't implemented due to the complex math which I have no clue why or how it works
MOUSE CAPTURE SUPPORT
(text is BOLD if supported & tested)
[text is striked if an implementation is not currently feasible]
([text is underscored if it's buggy or partially implemented])
- positionOnScreen (Windows, MacOSX, Linux)
- positionOnFocusedWindow (Windows, MacOSX, Linux)
- positionOnHoveredWindow (Windows, MacOSX, Linux)
I have marked positionOnFocusedWindow for MacOSX as not currently feasible
Although it may be, it's hard to find anything about the MacOSX api for c and c++
doing this in objective-c would be a breeze
So it is possible but unless I find something worth while for the c/c++ I don't plan on implementing this function
Which would require mixing of objective-c and c++
The hacky way is to take a window and continue to use CGWindowListCopyWindowInfo and continue to search up using the Window ID as refrence
some useful reasources:
- https://developer.apple.com/documentation/coregraphics/1455137-cgwindowlistcopywindowinfo?language=objc
- https://developer.apple.com/documentation/coregraphics/cgwindowlistoption/kcgwindowlistoptiononscreenabovewindow?language=objc
- https://developer.apple.com/documentation/coregraphics/kcgwindowlayer?language=objc (maybe?)
- https://developer.apple.com/documentation/coregraphics/kcgwindowisonscreen?language=objc (likely obsolete by using
kCGWindowListOptionOnScreenOnly)
After a nap later I'm ready to get back into it
kCGWindowBounds
Pretty neat
Ok so upon further inspection window layer != window level
I'm just going to assume what's at the top is what's focused
Which seems reasonable enough to me
though I still don't have a way of getting window level
I might be able to do a little tricky tricky hacky hacky
lets find out
Well for obvious reasons the terminals subprocess dosn't get detected seperatly from the terminal
but it now works (getting the active window)
It now somewhat works
It like to break when trying to use it on the Bongocat-Plus window, or the terminal running the process
positionOnHoveredWindow is possible on MacOSX
We can find the positions of windows
We can find the level of a window
And we know the psoition of the cursor
So we should be able to implement this with relative ease
Made some small pushes
I would work on the Windows and Linux versions right now, but I'm cold and don't feel like getting out of bed
Maybe I'll fix the bug on MacOSX with getting the window bounds
-- laad our images. LOAD BEFORE CREATING THE WINDOW!
local up = BongoSprite.loadFromFile("cats/pengu/up.png")
local down = BongoSprite.loadFromFile("cats/pengu/down.png")
local bg = BongoSprite.loadFromFile("cats/pengu/bg.png")
-- R G B A
local bg_color = Sfml.Color(218, 216, 254, 0)
-- states
local pressed_state = false
BongoWindow.create(612, 383)
while BongoWindow.processEvents() == 0 do
BongoWindow.clear(bg_color)
-- state logic
pressed_state = isPressed(BongoInput.Key.Any)
-- draw the bg sprite to the window
BongoWindow.draw(bg)
-- draw if logic
BongoWindow.drawif(up, not pressed_state)
-- display the window's contents
BongoWindow.display()
end
TODO:
- add BongoInput.Key.Any
DONE
I would like to allow ternary to use any type? It would be nice
Or maybe just add a function like drawifelse
After some time I did decide to add a drawifelse function with usage like drawifelse(true_sprite, condition, false_sprite)
- with some modifications
The lua code for this test ```lua
-- laad our images. LOAD BEFORE CREATING THE WINDOW!
local cat = BongoSprite.loadFromFile("cats/original/cat.png")
local mouth_shut = BongoSprite.loadFromFile("cats/original/mouth_shut.png")
local mouth_open = BongoSprite.loadFromFile("cats/original/mouth_open.png")
local left_down = BongoSprite.loadFromFile("cats/original/left_down.png")
local left_up = BongoSprite.loadFromFile("cats/original/left_up.png")
local right_down = BongoSprite.loadFromFile("cats/original/right_down.png")
local right_up = BongoSprite.loadFromFile("cats/original/right_up.png")
-- states
local left_state = false
local right_state = false
BongoWindow.create(800, 450)
while BongoWindow.processEvents() == 0 do
BongoWindow.clear(Sfml.Color.White)
-- state logic
left_state = isPressed("z")
right_state = isPressed("x")
-- draw the bg sprite to the window
BongoWindow.draw(cat)
-- draw ifelse logic
BongoWindow.drawifelse(left_down, left_state, left_up)
BongoWindow.drawifelse(right_down, right_state, right_up)
-- display the window's contents
BongoWindow.display()
end
Here is the GIMP file I had to create for the next skin I'm making
this just the catbanner.jpg reconstructed into it's original parts (seeing as I lost the original GIMP file)
The code for this is extremely similar to [this](#1063894460959834116 message)
Just a 2 lines removed, 2 added, and 1 modified
Ok made all my changes and pushed them to the repo
Closed major issue (marked as enhancement) #18
New cat dropping?
I plan on adding the typing you see in the video, along with the sounds
Athough for right now, all I have is this
Created a project board: https://github.com/users/ZackeryRSmith/projects/3
I cannot state how much work binding SFML to Lua is
Manual labor, it's not even difficult just time consuming
Then after that having to write a stub file for autocomplete in lua
Alright I may be dead inside but audio should now be supported
Yes although very basic and messy it's supported
I would like to handle playing the sounds myself rather than SFML dealing with it
As currently the way SFML handles it isn't powerful enough to do what I want with my API
I want to implement all the cats shown on this site later: https://www.laitimes.com/en/article/35mvn_3mcc2.html
A cat I want to implement
Maybe even being able to capture the entire screen or just a window and display it where the code is? Quite ambitious but cool
Made some pushes to the refactor branch
Need to add drawing at a position
I have created a few others
but they aren't really important
New cat drop
And here is the lua for that (the first time ever I've had to send the actual file)
I'm going to drop these for now
Of course I wouldn't drop issues for no reason. The actual reason is listed in the closing comment of the issue
Impressive
Is that in a sarcastic way?
I plan on changing the banner in the readme to this silly little gif
This thing
This is now done on the refactor branch
Refactor is now the default branch (despite it's incompletion), the reason why is noted in the readme
Compiling on Windows has always been a pain
To get passed using NMake you must specify the generator you want to use
in most cases -G "MinGW Makefiles"
Now I'm getting an issue with FetchContent_MakeAvailable
And that seems to be because I do not have git installed
Windows deps for compiling (so far):
- MinGW
- CMake
- Make
- Git
Yes! After installing Git all worked fine
MacOS deps for compiling (sor far):
- CMake
- Make
- Git
- SFML (recommended to be installed using Brew)
THESE ARE ON MACOS BY DEFAULT, BUT LISTED HERE JUST FOR CLARITY
- ApplicationService
- CoreFoundation
- CoreGraphics
I think i'd like to make a type racing cat
Something like this
but with a propmt
Ok just to get mouse support working I plan on just coping the unreadable code from the original Bongocat-Osu
I really do plan to refactor it all, trying to understand the math
I understand bout half of it, but rewriting it will take some time
Bongocat-Plus has 9 stars on Github ⭐
Not a crazy milestone but way more stars than any other project I've worked on
Added back enhancement from #19
This only works on MacOS for now, as the mouse functions all need to be implemented on all platforms
Issues with compiling Linux all stem from mouse handling errors
I'd like to avoid x11 but that seems unlikely
Regardless I will probably add support for x11 and wayland just to support most (if not all) linux enviroments
Improved readme build section quite a lot. Compiling no longer is (much) different between platforms.
I also changed up the "About the Project" section
I have created aa new issue tag food, slapping that tag on issue #55
Improved the CMake, making sure the syntax and style is consistent
Along with adding some fun features to the CMake
-DFORCE_ANSI=true force ANSI regardless of OS
-DNO_APP_DIR=true hide app directory
-DNO_INCLUDES=true hide includes
-DNO_SOURCES=true hide sources with
-DNO_COMPILER=true hide compiler with
CMake does now show include files used in Bongocat-Plus
When talking about platform based linking, where it used to say *NIX SPECIFIC'S, is now replaced with MACOS SPECIFICS, LINUX SPECIFICS, or OTHER SPECIFICS
Uhhh, so Mac support for Bongocat-Plus may have to be dropped
