This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # babashka (1)
- # babashka-sci-dev (27)
- # beginners (13)
- # cljdoc (1)
- # clojure (24)
- # clojure-austin (1)
- # clojurescript (76)
- # data-science (18)
- # datomic (7)
- # java (2)
- # malli (7)
- # nbb (7)
- # off-topic (34)
- # portal (1)
- # reagent (9)
- # reitit (4)
- # releases (2)
- # remote-jobs (1)
- # shadow-cljs (11)
- # squint (7)
- # tools-build (7)
- # uncomplicate (1)
any good hints on object collision detection implementation techniques or libraries (that play along well with clojure or are written in clojure)? 2d will suffice
Afraid I don't have a link to a library, but this may be worth considering: Many games wrap bounding boxes (simple polygons) around objects to make collision detection more simple/fast. If you use rectangle bounding boxes around your objects, then it would be pretty easy to write the collision detection from scratch (ie check if 2 rectangles overlap at all). A naive algorithm could just iterate over every pair of rectangles and check if they overlap:
(for[a (all-bounding-boxes) b (all-bounding-boxes)] (when (and (not= a b) (check-overlap a b)) (collision-detected! a b))
I used a clojure set in this tetris as I only needed pixels: http://github.com/invertisment/cljs-tetris But your game may be more complicated.
I'm implementing a bullet-hell game in Clojure, using LibGDX and its Rectangle class has some methods to check if they're overlapped. @UJVEQPAKS I tried to implement my own algorithm, but it's not as easy as it sounds, at the end you will be implementing something that has already been done by some library.
I think libGDX must have something that's already been thought of and is performant :thinking_face:
It's possible that in this case there is a need to use OOP for performance. Maybe it's possible to design a pipeline, but why not create an abstraction on top of this fast OOP implementation instead?
Folks, am I crazy or recently, Apple wants open-source developers to pay $99 a year and own a mac just to be able to generate a binary where they don't say it's "corrupted"? Is there some alternative? I mean, working "for free" is already bad enough...
if you download a binary through another program (e.g. zsh + curl, etc) those binaries won't be affected. only if you unzip them using Finder, etc
Ouch indeed... I wonder: Is it possible to use hosted MacOs to make these builds? Or does AAPL demand some sort of user account tied to developer-owned device/hardware?
I never tried, but hosted "should" work: what rules is the developer's apple-id which is tied to all the bureaucratic paraphernalia (certs, keys, etc.)
What do you think about not providing your software to them? 😄 They don't pay you for it anyway... why should you pay them? You're solving their problems and now you have to... pay for it.
It seems like the community is somebody who is offered mercy by this company. Is it really this way? Maybe it's a message that they don't really want you there?
I get it that you could probably hack your way out of it. But once they start seeing that somebody hacked their payment model... why not stop before it happens?
You could say "Hey, apple didn't want to have me so my builds are signed only by my own key, sorry; This is my own key which you can use to verify the integrity on your own if you trust me; You could instead pay me $5 to download
cowsay with correct signature on it"
The problem, @U47G49KHQ, is not the "process" of signing, but the fact that only if I pay $99 per year to have a certificate users' can install the app without any issue. I am not aware if I can simply not pay and users can at least install the app - it doesn't seem to be the case with Silicon macs anymore.
@U3Y18N0UC you can initially ask people to do this:
and just not sign, until you figure it out or someone with an apple accounts volunteers
sudo xattr -r -d com.apple.quarantine
> only if I pay $99 per year to have a certificate users' can install the app without any issue Oh, that's a bummer. Walled gardens :face_with_rolling_eyes:
@U04V15CAJ yes, that's what we've been telling users to do. Most of them don't read though
@U051MHSEK it's for Pulsar (Atom fork), we're lucky we even were able to build a native Silicon Mac DMG 😄.
Now, what makes me mad is: why is this acceptable? I mean, for Intel macs it was a popup saying "Apple could not verify the identity of this file, it might be dangerous" etc etc... Silicon straight up says "This app is corrupted, you should move it to trash" unless you run that
This is what happens when nobody buys these blackberry and windows phones... https://www.statista.com/statistics/266572/market-share-held-by-smartphone-platforms-in-the-united-states/
is distributing via homebrew or nixpkgs a viable option for your case? @U3Y18N0UC
So, is there a way to avoid $99 per year if I choose to distribute over homebrew?
I'd be surprised if a large loophole like that existed. I suppose the $99/year participation tax is Apple's way of saying "talk to us only if you're serious, where serious means business not fun not open source not playful creativity".
Let me correct your thought a little bit: "talk to us only if you're serious, community work isn't something serious" Also this: https://abopen.com/news/european-commission-report-declares-open-source-software-and-hardware-to-be-a-public-good/