I worked on it,
See?
1 Like
yeah this is really cool
Welcome back @Sketchy!
meanwhile, bro is on another topic telling him “no click big bad button”
2 Likes
The devices category is for ongoing research in gimkit. Previously, we used to put rule-breaking posts in the devices category, so we made research to find the real devices topics easier.
2 Likes
wow this is cool (/j)
(nobody, not even mods are safe from the /j >:3)
You could lower the resolution of what ever you generating, sorry if this makes no sense and is not related Im trying my best 
No, just no. He literally just said not to do this.
Thats what I was going to say
1 Like
now it feels like we are bots when doing that but to answer your question
yes
OMG who let @Blackhole927 BLACKHOLE cook so good with these guides?! sorry off topic
I quitted adanvce gimkit a long time ago.
but maybe a little tip won’t hurt
Texture atlas filled with glyphs is the most common way to render text with the least amount of draw calls.
1 Like
ok, ima first try to upgrade the line algorithm:
make a black square from past squares+1
So that the the black square row above is always one square longer than the past one:
Alright to do this we do:
(wait ima build this in gimkit)
So what is this basically? because the ultimate text display I would expect would be detailed typography animation. Because when you said draw it sounds like you’re trying to recreate a platform like kleki or Canva. Except very uh strange and wouldn’t this be similar to the 3d rendering from a while back?
No, typography isn’t a priority. Typography relies on filling algorithms and the rendering of bezier curves, and there’s a very cool Sebastian League video on it if you want to learn more about it. We want to make the fundamentals, like likes, shapes, maybe beziers, so that we can then use those basic tools to make more complex things.
The Text Rendering Video
1 Like
I clicked on the link second guessing myself if it was rick roll ._.
bump
1 Like
Assuming this is still a thing…
It sounds like the iteration by pixel is too slow, but I can’t see any fast enough alternatives. Doesn’t the mechanism, by definition, have to change every pixel? Is there a way to change multiple at once with a small enough lag penalty, while knowing which specific ones to change?
Since you can’t import and read images into Gimkit, you’d have to have a program that contains all the information for the image already. The fastest way I could see of grouping them is the same thing I thought a while ago with a way of storing terrain to save memory: storing the largest squares or rectangles possible. For example, if we have an image where the top quarter is all black, we can just save that as the top left coordinates and then the side lengths. Unfortunately, that doesn’t save much rendering time; it just makes it easier to enter into the system.
2 Likes
I propose using custom fonts to represent multiple lines or words which would reduce the amount of updates needed by a substantial amount, however, this is only in theory and I haven’t attempted an implementation of such technique yet.
(If you were able to represent 3 letters with 1 letter, you can have displays 3x bigger than right now)
WOWZERS this is cool.
now make it spin :3