There's already sudoku games out there for the CSE, but I felt like making one in assembly for funs, as a quick break from doing stuff with my isometric renderer. (http://i.imgur.com/6g9wxFK.png)
Anyways, I've got some code from an old attempt I might re-use, not sure yet, but right now I'm just generating puzzles.
I wrote a puzzle generator in haskell to see if I could do it, and it works pretty well, so I'm letting that run for a bit.
As much as I'd like to generate puzzles on the CSE, it turns out proper puzzle generation can be a bit processor heavy. Instead, I'm going to focus on making the core of the game small/lightweight, and then (if I have enough puzzles) release a few packs as either different programs, or a collection of appvars. Really it just depends on how compressible the puzzle data ends up being.
Screenshots tomorrow maybe if I get any coding done. And by tomorrow I mean today, I'm going to sleep right now @ 6 A.M.
Oh cool :) also the isometric renderer looks really cool too :)
Yay sudoku! I suggest AppVars for storage though.
Problem with appvars is it makes loading way more complicated, especially if they can be archived.
Cool, :) the CSE or CE is my next calc ;)
Also the Isometric renderer looks awesome :)
You could maybe include some pre-made puzzles if speed is too much of an issue. I would like to see Sudoku on the CSE. That isometric tilemapper also looks nice. :)
I've generated 6750 puzzles so far and counting :P
Wow, that's nice then. :)
How does? huh?
Unicorn is not smart enough O.O
Well, that means there are enough puzzles to solve
Ha, no kidding. If someone solves them all, they should get a badge :P
Alright so some math stats
I did some tests on the puzzles I have right now. They're all what I'd classify under "hard" or "very hard" difficulties right now, but don't worry I'll be converting many to easier puzzles.
Anyhow, given my current set of 8321 puzzles:
These puzzles have on average 24-25 starting numbers. The rest are all zeroes.
I can compress them down to, on average, 22.32 bytes per puzzle.
That means that in 4096 bytes I could store about 188 puzzles.
Realistically it will be less because easier puzzles will take more space, but this is pretty good when you consider a full board is 81 numbers. I'll have quite a few puzzles included and I might not need separate puzzle packs for them.
EDIT:
Oh and the way I'm compressing them is I'm storing them as a series of bits.
To store an empty tile, I have a 0 bit.
To store a non-empty tile I have a 1 bit, followed by 4 bits representing the tile's number.
Pretty simple really.
Thats quite a cool compression algo O.O
Quote from: unknownloner on June 12, 2015, 09:03:58 AM
Alright so some math stats
I did some tests on the puzzles I have right now. They're all what I'd classify under "hard" or "very hard" difficulties right now, but don't worry I'll be converting many to easier puzzles.
Anyhow, given my current set of 8321 puzzles:
These puzzles have on average 24-25 starting numbers. The rest are all zeroes.
I can compress them down to, on average, 22.32 bytes per puzzle.
That means that in 4096 bytes I could store about 188 puzzles.
Realistically it will be less because easier puzzles will take more space, but this is pretty good when you consider a full board is 81 numbers. I'll have quite a few puzzles included and I might not need separate puzzle packs for them.
EDIT:
Oh and the way I'm compressing them is I'm storing them as a series of bits.
To store an empty tile, I have a 0 bit.
To store a non-empty tile I have a 1 bit, followed by 4 bits representing the tile's number.
Pretty simple really.
"hard or "very hard" O.O (I don't even know how to play Sudoku :P)
Why not just RLE? If many of the puzzles will be full of zeros, RLE would do a very good work on it.
RLE could do it, but I guess it will show less gain over this particular algorithm (except if you use bit instead, but it start to be a bit more complicated).
Quote from: unknownloner on June 12, 2015, 09:03:58 AM
Alright so some math stats
I did some tests on the puzzles I have right now. They're all what I'd classify under "hard" or "very hard" difficulties right now, but don't worry I'll be converting many to easier puzzles.
Anyhow, given my current set of 8321 puzzles:
These puzzles have on average 24-25 starting numbers. The rest are all zeroes.
I can compress them down to, on average, 22.32 bytes per puzzle.
That means that in 4096 bytes I could store about 188 puzzles.
Realistically it will be less because easier puzzles will take more space, but this is pretty good when you consider a full board is 81 numbers. I'll have quite a few puzzles included and I might not need separate puzzle packs for them.
EDIT:
Oh and the way I'm compressing them is I'm storing them as a series of bits.
To store an empty tile, I have a 0 bit.
To store a non-empty tile I have a 1 bit, followed by 4 bits representing the tile's number.
Pretty simple really.
Will they be in order of difficulty? Some games often add super hard levels just between two early easy levels.
You'll be presented with a choice of difficulty, and after selecting a difficulty you'll be able to choose a board from it.
Ah I see. Seems good to me. Will the harder boards in each section only unlock themselves after beating the previous one? It would be nice if the game showed which one you have beaten at least once so you can 100% the game.
It'll show you which ones you've beaten, but there won't be an unlocking system. I don't really have a good way to judge how difficult a board is other than to count how many numbers are given to you when you start, so it's just going to be organized based on that.
Aah that still seems good to me at least. It just sucks if there is no indication about which level you have beaten in a game and you try to remember. :P
(http://i.imgur.com/jzJFSpZ.png)
Not much but we're gettin' somewhere
For a level editor?
Nah, just figuring out how I want the board to look. I feel like a level editor is too niche for a calculator sudoku game.
Ah, I see, also nice signature :P
(http://i.imgur.com/PFLldmJ.png)
Now with 20% more numbers!
This actually loads from my compressed file format too, so that works!
whoa that looks kinda cool! How is the letter drawing speed and such btw? (since it still is the cse :P)
It's not bad. It could be a bit faster if I went for speed over size but I think the current speed will be fine
Seems pretty good so far. :) How large is it right now?
^
I like how crisp the letters are.
1700K I believe.
The font is Terminus btw, it's a bitmap font so it works really well for making calc fonts.
Though the CSE letter layout in bytes is ridiculous. 2 bytes per line of 10 pixels <_<
I'm actually storing it as 1 byte per pixel, and then compressing that with LZ4. That comes out to 216 bytes, while if I stored 2 bytes per line it'd be 300 bytes.
Originally I did this so I could use DCSE's "transparent pixel" feature in its 8-bit sprite routine, but I ended up not using that. I figured I'd keep it at 1 byte per pixel though since it was smaller to store.
Yeah it would be insane if we were forced to use 16-bit colors just to have custom fonts and use 2 bytes per pixel for them. Since your fonts are quite large this would have made the file size skyrocket despite the fonts only using two colors.
WOuld it be too slow if you compressed them to the same format as TI-83+ pics (1 bit per 8 pixels)?
Quote from: DJ Omnimaga on June 22, 2015, 06:03:12 AM
WOuld it be too slow if you compressed them to the same format as TI-83+ pics (1 bit per 8 pixels)?
TI-83+ pics are 1 bit per pixel, not 1 bit per 8 pixels.
I don't compress them to 1 bit per pixel because it results in a larger file size than LZ4 w/1 byte per pixel, as mentioned in my previous post.
Ah my bad, I made a typo. But yeah I meant 1 byte per 8 pixels. And I see. I didn't realize it could end up larger that way.
It's basically because numbers in fonts have a lot of repeating sequences of bytes. For example, think of a 0. All the middle rows are the same, so once it's written out once the compressor can just refer back to the previous data.
Yeah true. I just didn't realize that the data was so simple enough to end up being smaller than 1-bit graphics. By the way, how is this project going on? Do you plan to make a CE version?
When I end up finishing this I'll add it to the list of things to port to the CE. Once I get a CE I'm planning to port my ASM games to it, starting with 2048.
Quote from: unknownloner on July 04, 2015, 03:17:50 PM
When I end up finishing this I'll add it to the list of things to port to the CE. Once I get a CE I'm planning to port my ASM games to it, starting with 2048.
Not snake? O.O
I actually play your snake game very much. :P
CE ports of your games would definitively be nice Unknownloner. Hopefully it's not too hard to pull off. :)
Quote from: Unicorn on July 06, 2015, 09:25:29 PM
Quote from: unknownloner on July 04, 2015, 03:17:50 PM
When I end up finishing this I'll add it to the list of things to port to the CE. Once I get a CE I'm planning to port my ASM games to it, starting with 2048.
Not snake? O.O
I actually play your snake game very much. :P
Snake is one of my oldest games so it'll be harder to port just because I'll have to figure out how the code works.
Haha I had this happen with many of my old games. In one occasion I just said "screw it! I'm rewriting the entire thing"
Lol, I guess thats true. :P