I dismissed it as too technical for that blog post. I expected this post to be read by a wide variety of people, so I tried to keep technical stuff to a minimum. I did say it's simple and that it's what I'd probably use if I kept going with the project.
It is written in Lua and the source code is available (just extract it from the PC version). It's using Lua's number type for all numbers, which is a double precision float.
Thanks for the clarification (I'm the blog author). If one were to really make this game, how the cards would ultimately be rendered is hard to say. Sprites are nice because you can overlay them and form many card variations from just a few sprites. Tiles rendering into a background doesn't account for transparent pixels, so building up tiles into a single background is not possible.
One way to handle that is to provide all the possible tile variations, but that would take up so much space. So you'd have a set of tiles for a regular Ace of Spades, and an entirely different group of tiles for a Lucky Ace of Spades for example.
The GBA has 4 backgrounds, so it would be doable to grab three of them and use them to render cards. That would only leave 1 background left for, well, the background :)
Another option would be to use a memory buffer and implement tile rendering yourself that accounts for transparent pixels. That would be the best of backgrounds and sprites combined into one. That would solve many problems, at the cost of the implementation would probably take up a lot of space. My hunch is this would be the best approach.
This right here might be why I find this platform so interesting. It's very limited, and the limitations usually bump into each other and you often steel from Peter to pay Paul.
Oh and the post didn't mention debuffed cards (they have a red X drawn over them). That'd be yet another card layer to throw into this mix.
I'm the author of the blog post. I just used sprite positioning as a simple example. Things like collision detection and physics can't be done with half pixels.
Trying to read between the lines here, if your objection is to half-pixels because they’re not precise enough for (good) physics, then I apologize for being unclear - I mean half-pixels, or quarter-pixels, or eighth-pixels, or whatever.
Another way of wording my comment is that I think it’s easier - especially for beginners - to think in terms of smaller units (represented as integers) than in terms of a new number format for representing fixed-size fractional parts of larger units. But the two concepts are ultimately the same.
But that's basically what fixed point is, no? Half pixels is fixed point with a single bit for decimals. Quarter pixels is two bits, and so on. I think the disadvantage is you now have to think in a strange unit that isn't intuitive. For my game I tend to think in screen sizes for things. Thinking in screen size*factor would be harder I think. Fixed point is basically just doing that for me and hiding the details really.
To be fair, rereading the post I realize I did make it sound like you would only need this for positioning sprites. I'll see about rewording it.
Or maybe we're both talking about the same thing and you're taking a different approach. That is fair too.
Yeah, we're technically talking about the same thing - just a different way of thinking about it.
When I was learning retro game dev (mostly Game Boy), I found fixed point very intimidating. Reading stuff like "the player will move at 1.5 pixels per frame, and to store the decimal point we'll use this special format where certain bits represent the fractional part and certain bits represent the integer part" scared the heck out of me when I was still, like, coming to grips with binary representations at all.
Whereas "the player will move at 3 half-pixels per frame" is just a really straightforward conceptualization. The data representation is the same, the code to convert from half-pixels to pixels is the same, but one way of understanding it feels very technical and abstract.
Especially when working in assembly language (like I was), where you don't really have any kind of typing mechanism, it never really made sense to build a fixed-point data type abstraction.
And, to be clear, I'm not trying to give you, specifically, any guff for this; it's as fine an article on fixed-point that there is.
I almost never say "you're wrong", no matter how confident I am. Because I can be, and often am, wrong myself. If there is a disagreement, a miscommunication, etc, why not instead work with the person to find where you two differ and look for common ground? If the other person really is wrong, it's almost always naturally revealed that way.
I disagree. If Monty always reveals a goat, there is no tension. You know exactly what is going to happen. Maybe it could be used a way to pad the running time of the show, but it would not add tension. "Coming up next: Monty reveals what's behind one of the other doors!" seems like something a game show would do. Whereas "Coming up next: Monty reveals a goat!" does not.
Yeah, you make a good point. I can sort of see it both ways, I think it would depend on how the show handled it. Leaving it across a commercial break then yeah it probably does make more sense the door is random.
Oh interesting. I never would have thought AI would be used for this. Does it also find things like the meta "revised" tag or anything like that? Doing some Googling it seems like officially it should be "revision", but seems like it's very common to use "revised"
But a few websites set their updated date to the current date which was annoying, maybe to rank better in Google? And some people (including me) only mention the update time in the page text content.
I've used GPT to parse human formatted dates in another project too, it's quite reliable if you validate the output timestamp. And relatively cheap too if you only pass in the first part of the page text.
I can see how it's a tricky problem. I wish html had more structure here (and people followed the structure, a whole other problem...). FWIW, my page has a "last updated" date on its now page but comes up as 1969 in aboutideasnow.
I know we're just going to have to agree to disagree, but I find utility class based projects easier to maintain. Coming back to -- or inheriting -- css soup is never fun.
> I think people compare the best possible CSS with Tailwind rather than comparing what actually gets done with actual Tailwind.
Yep. The one Tailwind guy on the team will set everything up perfectly, and then no one else will ever have any desire to ever learn Tailwind, and it descends into a complete mess.
You can say "just learn Tailwind!", and see how far that gets you with a group of backend devs who've inherited some UI and just need to add a button.
> utility classes won’t let you deviate because they’re limited
Tailwind's just in time feature does negate this a bit. I'm a huge fan of Tailwind but I've largely avoided JIT for fear of losing the structure finite classes give me.
Edit: the down votes are interesting as this is literally what Tailwind JIT allows. Their post on it even says "We’ll likely add some form of “strict mode” in the future for power-hungry team leads who don’t trust their colleagues to use this feature responsibly."
