And the panic starts

So I'm a tender young lad, and my A-level results are rolling in tomorrow, apparently, and on the 19th (Aug), I have to go into college, and beg for a place on the second year.

I've always been confident as hell in exams, and things, but holy balls am I dreading the results.

As such, my coding has fallen to a standstill, and I've lost my will to game.

Expect few updates.

The 90% theorem.

I can complete 90% of a version 1 at 100% speed, then the remaining 10% at 0-10% speed.

Yeah, I haven't worked on multicrop for a while now. Been playing around with ScrollDem. Interest seems very low, but I'ma carry on with it, 'cause I use it.

At the moment, it loads up a folder full of files, pads them with zeroes if necessary, then lets you scroll smoothly though them. There's a glitch with doublebuffering which I've still not been able to figure out how to squash, but it doesn't really affect the program's operation, and seeing as doublebuffering makes the whole thing run alot better, I'm not too fussed.

A much bigger problem is that because I'm loading up to 129 images, all of which can be over 5k*5k, and then they're all being converted to uncompressed bitmaps, or whatever they are, in memory, I use ALOT of RAM. My moderately sized set of images (smaller than 1920*1080) chewed up just under 1GiB of memory, and the features I had in mind for future development of the program will double or triple that number, in the program's current state.

The solution that looks the simplest at the moment is only keeping a few in memory at once, and loading an unloading images dynamically, but that's gonna be a bit of a major restructure, and I'm pretty sure that with the larger files, it'll be hella CPU intensive. I also think it'll need to be done with threading to maintain the "smooth" aspect of the program, but then that introduces alot more kerfuffle with potentially blitting a surface that doesn't exist, if someone scrolls too fast.

Not to mention threads are a giant bitch to implement. Especially when I'm this far along.

Well I've come a fair way

I did in the end choose to run the whole app fullscreen. Refactoring the code was much faster than I anticipated, managed it in about 10 minutes.

Also, the code worked flawlessly on the laptop, so many a college afternoon were spent happily coding away.

Progress has been in excess since the last update, as I believe I left here with just the path selection screen functional. This now does all sorts of boilerplate things, such as adding a trailing sep, if needed, leading a directory, stripping all ineligible files, and having a list of paths to files magically appear. All quick work; done it hundreds of times before.

After that, it was time for the next section of code. So far the intro is done, leaving the selection/main input section, and the functionality section.

Onto the main input section I went, and that's pretty much where I remain now. It's a biggy.

I won't bore you with the details, but the main chunks of code I've implemented so far are crosshairs as the mouse pointer, to make for more accurate selection, being able to click-drag the canvas, (which was a bugger, due to blitting taking ages, and other such nonsense), and placing crosshairs, which is what I'm on now.

The code I have works, but fairly shoddily. The crosshairs, when placed, jump up, and to the left slightly. Not a gigantic worry, and I could just offset the values by a constant, but I have absolutely no guarantee that that approach would remain accurate on different resolutions, and certainly doesn't fix the problem, only the symptoms.

I'm going to leave it as it is until I have a working prototype, so I can worry about it then.

Next little bit I have to do is passing the right pygame.Rect to the functional section of code, then do some silent iteration, and close tidily. It'll be lovely to see that "print("EOF") at the footer of the code, reached.

Outside of multicrop, and indeed outside of Python entirely, CCP have told me that C++ would be a wery good idea, so I'm teaching myself that. I learn to swim best when I'm at the deep end, so I'ma jump in with some OpenGL nonsense, and play with that, but just being able to do that is a chore. Every tutorial/code sample I've seen out there has been windows-specific OpenGL code. Sometimes with DirectX handling input, and sound, etc. What's the f*cking point?

Yes, I've been super-detached and lazy

Update coming soon, don't you worry, but first, I feel an update on the EVE CSM is needed:

CCP has removed a player-elected, virtually powerless spoekeswoman for their internet spaceship game. Cries of "grr, CCP must do thus and such!" aren't going to have a lot of weight

Morning thoughts.

After a night of no sleep. Thus, the thoughts will be gibberish:

-No reply to mah threads asking how to resize window
-If I don't code for a while, I'll not code for a while
-Would be faster to refactor(?) the code, and run the entire thing full-size.

Well, we'll see how it goes.

Before I'm heading to college today, I'ma see if what I've written so far works on the laptop, 'cause if it does, I can take it to college, and work on it some more, there.

A continuation. Less delicious.

PREVIOUSLY, ON FAGMAN:

Asday: "Hey look, I will write some code."
CPU: "OHHAI, I'M GTK+, HOPE YOU DIDN'T NEED TO USE ME ImportError ImportError ImportError ImportError ImportError."
Asday: "PyGame! I choose you!"
CPU: "Enjoy wrestling with graphics.
*fun ensues*

THIS TIME:

Just added a short selection block that checks if a path exists before progressing, and discovered that I haven't allowed the ":" symbol in path names.

I can see where that will fall down.

Anyway, with that fixed, it's time to discover whether I can change window size or not. :3 If I can't, this might get messy.

-LATER-

Ok, just managed to change the window size (I think), but it's a little hacky. As evidenced by the epilepsy-inducing flashing, and general deathly throes.

-LATER-

Ok, kinda hit a brick wall here; so I've asked the internet, and I'm waiting on some pointers.

A beginning. Delicious.

So this post on the minecraft forums got me itching to code again, and Andrew Nare's blog seemed like a fun thing to do, so here's my take on things.

First, though, a little on me. I've been self-teaching myself, (as opposed to self-teaching Buddha), Python for just over a year now, I'd say, (preceded by a little VB.NET, ugh). I've decided that working up a portfolio would be a good idea, so today, I'm starting small.

After wrestling with GTK+ for about half an hour, I decided to give up on it, and use PyGame for the visual bits. Makes more sense anyway, I suppose; I believe it's easier to find the mouse, etc.

Sadly, my notes on what I should do are somewhat... Lacking.

import pygame
import Image as img

#img.open()
#img.crop((l,u,r,d))

#pygame 2 bits; upper = image, full size scrollable, middleclick+drag for
# movement, lower = instructions.

#type path, list of files, strip any not images

#click top-left, grab co-ords, click bottom-right, grab co-ords

#gogogogogo


Still, better than nothing, I suppose, so, first thing I'll do, is figure out how to make a simple window, with an entrybox on it, where the user can specify the path. Then some simple ifexists, etc.

-LATER-

Ok, so, played with PyGame for a bit, and did all the flippy goodness, etc., and didn't realise the default background colour for my screen was (0,0,0), and predictably, I rendered my text in black; so I dunno if it worked or not.

On the other hand, I got my head around events, so that was nice.

-LATER-

Ooh, interesting, when you backspace a character, it doesn't clear it visually, so if you type something, backspace it, type something else, backspace that, rinse repeat, it gets wery messy. Same sort of thing happens with anti-aliasing, (so characters get very chubby.) Fixed both with liberal application of surface.fill()

More to come.