Hey guys, sorry. I didn't realize I'd be the only person with the OS. I gave DJ the link so you should have a news shortly. I'd post the link here but this is news worthy.

I know I'm not the only one who has wanted to make a long exposure picture but didn't have the camera to do it. So I made a C++ program that will convert a video into one of those pictures. And after about 2 weeks, it works!!!

This is one of the coolest programs I have ever made. You just take a video file, send it through my program, and get a picture.

I am using DirectShow to do most of the dirty work for me. It parses the video file and gives me a copy of each frame which I then average together. But simply averaging isn't enough because it results in pictures that are very dark. I take each pixel to the 8th power, average them all together, then take the 8th root. This means that little bright spots get really bright, and bright pictures probably turn white.

To use it, the syntax is      longExposure <video> <picture.bmp>      . The video can be anything that DirectShow supports, but to be safe, I'd just use .wmv since DirectShow is made by windows. I'll also have to see about exporting these as .jpg because .bmp sucks.

As for what you need to run it, I feel bad for whoever tries first. I know you will need C++ runtime libraries (x86 x64). And you will probably need DirectX as well.

Here are some pictures that I made in my basement with a flashlight.

Eh.... Oops.

Not only is the current version slightly buggy (I don't know why though) I screwed up on the AI detection for protected pieces. I'd fix it, but the current state of the program is super-unstable, so sorry about that

-----------------------------------------------------------------------------------------------------------------------------
That is how to not double post.

The last version sucked, so I fixed it. New features:
-Check detection is like lightning
-Checkmate/stalemate detection is way faster than before
-Option to not move cursor after AI moves
-Option to not show possible moves
-Moves that put your own king in check are no longer displayed
-New move cursor is now white and dark gray
-AI is fixed
-No-move stalemate detection
-50 move stalemate detection (50 on each side right?)
-Holding CLEAR and pressing ON aborts all processes and quicksaves the game

Just to give you an idea of why the AI takes so long, the AI routine maxes out at a nested 8 calls 10 loop and 57 pushes to the stack. Each of those 10 loops does 8 iterations, so 8^10= 1,073,741,824 possible trials of the inner code. (Not really though because ever square is not filled with a piece that can move to ever other square, but you get the idea).

In other news, I have passed TI's limit for a program (~8100). All this speed comes from specialized routines which take up space.

I was beaten by it for the first time today, but mostly out of stupidity

Sir, you have completed a milestone. This is the first time anyone has actually been checkmated by it, which is a good thing for me


Also, as for updates.
- new move squares are white and dark gray
- option to not move cursor to last AI move
- option to not show possible moves

Currently I'm working on really quick stalemate and checkmate detection. You might notice that the current version takes quite a bit of time to see if you are in checkmate.

For a really easy way that will work on all calculators. Output $81 (Ram page 1) to port (06) ($4000-$8000). Then jump to a [label in you program - $4000]. You are now executing in the $4000 range so you can do whatever with port (07). Then when you are done, put page $81 back into (07) and jump back.

Remember though, when you are executing in the $4000's, all the labels in your program are still back up in the $8000 range. So anything that requires an absolute address: jp; ld hl, (label in your program); and call; all need to be adjusted accordingly when you switch.

Post Post (Double post)

I promised an update the other day, so here it is. I was going to add the whole big list up there ^^, but I figured I better get a version out considering the current one still has the dark gray background.

Changes: (I think)
-Black background
-Game stops at checkmate
-AI understands unprotected pieces
-Save As...

As with customs, a screenshot is also provided. (Screenshots make it look like progress was made )

Sprites could be changed... If greyscale sprites are possible, they'd be great, but if you can't do that, at least change bishops and pawns. They're only two pixels apart, and it can get frustrating sometimes to tell the difference... =)

I agree that the bishop and pawn sprites are too close together, especially because when you highlight them, they look the same. However, I don't know what to use instead. The problem with grayscale sprites though is that it's hard to see them. The problem is that there aren't really any colors available to make the sprites with. You can't do much work with white and light gray because they are used in the board. Which only leaves dark gray and black, which depending on contrast, can look pretty similar.

Also, I personally think the selection cursor should be third-tier greyscale, or flash faster. I've made some mistakes because I can't tell the difference between the selection cursor and the possible-moves boxes. Also, I think an option to not show possible moves should be available as well, since it's just a distraction to some...

Changing the cursor isn't a bad idea, the question though would be which cursor to change, the current one or the new moves one. I'll make some changes and see which one looks better. I'll also add that option to disable the new move boxes, that's really easy.

The AI also tends to make really bad opening moves. I would recommend programming in a couple simple openings. If nothing else, have it start with king pawn or queen pawn most of the time... The game gets pretty bad when the AI starts by putting a knight on the rim. =D

For now, I'll probably leave the opening moves up to the AI. My goal is to get to the point where it figures out what to do by itself.

•make an option for the cursor to not change position after the AI moves

Ok, that's quite easy to do.

•take care of threefold repetition/50-move rule (if it's not too hard)

Those are the easy stalemates, I can do those with simple counters.

•take care of stalemate

Actually, after thinking about this. If I make a special stalemate routine, as opposed to using the AI routine to check for moves, stalemate detection shouldn't take more than .01 seconds.

•provide the AI with an opening book and endgame database, and make it so that it tries to checkmate, since even when I try to lose, the AI checks me perpetually or stalemates me (even when there is an obvious mate in one)

Again, I'm not going to do this for a while because it would be a heck of a lot easier if the AI can just figure it out.

•odds (show a chess board; the user can click a square to toggle whether he/she starts with that piece in the beginning or not)

So basically you can choose to handicap yourself? I'm not entirely sure what you mean.