Quick question about the rules: If the filesize of my program shrinks (fairly dramatically) after initial execution, will you overlook the initial filesize?
Kerm and I have yet to set up the final grading rubric (what we will be focusing on, and how much we want to), once we do, we will have an answer for it.
I am the eye of the river
>(<')
>(<')
rivereye wrote:
Kerm and I have yet to set up the final grading rubric (what we will be focusing on, and how much we want to), once we do, we will have an answer for it.
Precisely. Until we do, make the general rule-of-thumb assumption that the happier a naive end-user would be using your program and not getting annoyed or frustrated with it, the better of a grade we would be likely to give it. Keep in mind that we'll of course also be looking at technical proficiency, though, which a naive user wouldn't necessarily notice. 
I intend to write a shell expansion for DoorsCS that supports USB mice, the significant (and challenging) part being that it will NOT rely on usb8x, so it will be a fully-functional USB mouse driver (for use in DoorsCS) that fits within the 768-byte requirement.
BrandonW wrote:
I intend to write a shell expansion for DoorsCS that supports USB mice, the significant (and challenging) part being that it will NOT rely on usb8x, so it will be a fully-functional USB mouse driver (for use in DoorsCS) that fits within the 768-byte requirement.
Superb! I need to make sure that SEs are still able to use the register d outputs to affect movement and clicking; I'll let you know what I find. If I removed it for some reason (as I suspect may be the case), I'll be sure to add it back in. 
I have one suggestion.
Perhaps you should have stress testers on the deadline week.
We can't exactly find EVERY bug in our program and since we can't release our projects early, I just thought that this was the next best thing for debugging.
Perhaps you should have stress testers on the deadline week.
We can't exactly find EVERY bug in our program and since we can't release our projects early, I just thought that this was the next best thing for debugging.
Raylin wrote:
I have one suggestion.
Perhaps you should have stress testers on the deadline week.
We can't exactly find EVERY bug in our program and since we can't release our projects early, I just thought that this was the next best thing for debugging.
That sounds great, but I'm a little vague on what you mean by stress-testers as opposed to regular beta-testing. Perhaps you should have stress testers on the deadline week.
We can't exactly find EVERY bug in our program and since we can't release our projects early, I just thought that this was the next best thing for debugging.
Register to Join the Conversation
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement