city41

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.

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.

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.

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.

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.

Not to mention Monty always showing a goat is what adds the tension and interest a game show needs.

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.

Oh, now aboutideasnow shows no date at all.

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"

A lot of cards say "Updated December 31, 1969", what date are you all using to populate that?

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.

> 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."

Had a similar response. Dusted off my account and finally posted something.