Black does look the best. I bet more people would buy if black was the default. Keeping blue as default is just silly at this point.
Oscar, how about it?
Black rules. Blue sucks. If you think otherwise, you are wrong.
Ok, guys you both like black, so we made this as an option.
I should write a short history about every BASIC language having blue background, Atari 8-bit, MSX, Oric, etc. Kids programming happily with blue background, etc, etc. Nobody complaining, etc, etc.
So I like blue and it's my favorite color and I use my developer prerrogative to start it as default and every beta tester didn't complain and there were 8 beta testers... so "liking+doesn't matter versus unlike" is equal to blue > black, or 90% people prefers blue
Sorry guys, we won but both of you got your option
Let us suppose you have your 7x11 image in a single BMP file measuring 56x88 pixels, and same with other image.
intycolor -b -n image1.bmp image1.bas image1
intycolor -b -n -o32 image2.bmp image2.bas image2
Note the use of offset 32 in second image, why? because both images must use non-conflicting GRAM, otherwise you'll see trash in the change (another option would be to put the frame in black while defining GRAM)
Supposing each image used only 16 GRAM.
FOR c = 0 TO 60: WAIT: NEXT c
FOR c = 0 TO 60: WAIT: NEXT
This code will overlap the image alternating between the two at location 26 of screen.
Note how the code gives the X size and Y size in cards, and ALSO the final argument is the width of the source image in cards.
Making everyone happy was kind of hard...dinosaurs, aliens, and sharks, then we discovered one of the testers meant "Indians," not "aliens"...nanochess added the Indians but we had a hard time getting their elephant's ears correct...
Hey! I thought we had agreed to not talk about the aliens game we're making
I ran into something that might be explained by the above. A sample program using the compiler version 1.2.8:
PRINT AT 0 COLOR $0007,"D=ABS(C)*2:"
PRINT AT 12 COLOR $0007,<>d
PRINT AT 20 COLOR $0007,"#E=ABS(C)*2:"
PRINT AT 33 COLOR $0007,<>#e
PRINT AT 40 COLOR $0007,"#G=ABS(#F)*2:"
PRINT AT 54 COLOR $0007,<>#g
It displays D=150, #E=65174 and #F=150. Perhaps that is expected behavior given the above?
In my case, I can use 16-bit variables all the way but for those cases where the value is known to fit within 8-bits, I would prefer to use one of those.
(Edited due to the AtariAge forum eats anything that is below code fragments unless BB Code mode is switched off)
The behavior is all right.
Let me explain the IntyBASIC expression processing:
1. Every arithmetic is done internally in 16 bits (the register size) 2. SIGNED affects the reading of 8 bits variables (extending them to signed 16 bits, default is reading as unsigned) 3. SIGNED/UNSIGNED affects a single flag while processing expressions that switches between signed comparison and unsigned comparisons. 4. The PRINT <> operator always shows the 16-bits numbers as unsigned.
So the advantage of SIGNED with 8 bits variables is that it allows to add negative numbers to 16-bit variables without using the precious 16-bit space to preserve the value or manual sign-extending operations.
#a = #a + b ' b can be -128 to 127
The advantage of UNSIGNED with 16 bits variables is that it allows to calculate carry very easily.
points = 5
IF score(0) + points < score(0) THEN ' Carry over (easy with UNSIGNED)
score(1) = score(1) + 1
score(0) = score(0) + points
Applying UNSIGNED to a 8-bits variable doesn't make anything because is the default behavior.
Likewise applying SIGNED to a 16-bits variable doesn't make anything because also is the default behavior.