@RonJeffries - haven’t had much time recently to play, illness in the family, so this has been slow in production. It’s just an example of the controls I posted about earlier, just an idea which combines the power and direction controls for the ship - with a large area for the firing button. Still have some ideas to check but will be a while forthcoming.
One thing, with not having used it for years I struggled to get the sound operating effectively, code below fires up errors so any ideas around that would be appreciated.
I think the controls idea is fairly obvious
displayMode(FULLSCREEN)
function setup()
--
assert("Please ensure your sound is enabled")
cW,cH = WIDTH/2, HEIGHT/2
angle = -180
padLoc = vec2(100,140)
padSize = 180
goSize = 80
go = false
padCheck = padSize/2
goCheck = goSize/2
bpX,bpY,bpS = 172,141,32
butPos = vec3(bpX,bpY,bpS)
fire = vec4(WIDTH-180,180,240,240)
ship = readImage(asset.builtin.Space_Art.Red_Ship)
trail = readImage(asset.builtin.Tyrian_Remastered.Flame_1)
bang = asset.documents.Sounds.fire
end
function draw()
--
background(40, 40, 50)
pad()
pushMatrix()
translate(cW,cH)
rotate(angle+90)
if go == true then
sprite(trail,-0,-60,-20)
end
sprite(ship,0,0)
rotate(90)
popMatrix()
rectMode(CENTER)
noFill()
stroke(254, 63)
rect(fire.x,fire.y,fire.z,fire.a)
collectgarbage()
end
function touched(touch)
--
checkX = math.abs(touch.pos.x - padLoc.x)
checkY = math.abs(touch.pos.y - padLoc.y)
checkGX = math.abs(touch.pos.x - goCheck)
checkGY = math.abs(touch.pos.y - goCheck)
if touch.state == CHANGED then
if math.abs(touch.pos.x - padLoc.x) < goCheck and
math.abs(touch.pos.y - padLoc.y) < goCheck then
print(touch.pos.x - padLoc.x)
go = true
else
go = false
end
if checkX < padCheck and checkGX > 0 then
if checkY < padCheck and checkGY > 0 then
angle=math.deg(math.atan2(padLoc.y-touch.pos.y,padLoc.x-touch.pos.x))
end
end
end
if touch.state == ENDED then
if isInside(touch.pos) == true then
sound(bang,0.5)
end
end
end
function pad()
--
strokeWidth(2)
stroke(255, 109)
noFill()
ellipseMode(CENTER)
ellipse(padLoc.x,padLoc.y,padSize)
ellipse(padLoc.x,padLoc.y,goSize)
pushMatrix()
translate(padLoc.x,padLoc.y)
rotate(angle)
ellipseMode(CENTER)
-- sprite(asset.builtin.Space_Art.UFO ,padLoc.x-170,0,32)
ellipse(padLoc.x-170,0,butPos.z)
popMatrix()
font("AmericanTypewriter-Bold")
fontSize(48)
fill(253, 66)
text("Go",padLoc.x,padLoc.y)
end
function isInside(t)
--
if t.x > fire.x and t.y > fire.y then
if t.x < fire.x+240 and t.y < fire.y+240 then
return true
else
return false
end
end
end
i think you'll find that calling collectgarbage is undesirable.
it's an interesting idea, i'm finding it hard to work, but could just be me.larger pad might help me. i agree playing with just thumbs would be good. i might try plugging it in. also maybe make controls easier to modify for experimenters. thanks!
@RonJeffries - oops, left the garbage collection in whilst I was having issues with Codea. I operate by cycling my left thumb on the small inner circle for rotation, and just drag back/forward/sideways to fire up the engines. Changing dimensions may help, smaller inner 'Go' circle.
The large catchment area on the right, for fire, is easier to use.
Here’s something I have but I don’t remember exactly who wrote it. Maybe they’ll post and take credit. But you rotate the ship with a thumb and finger on the screen like you’re turning a knob.
displayMode(FULLSCREEN)
function setup()
touches = {}
touchpt = {}
angle = 0
sangle = 0
iangle = 0
end
function draw()
background(40,40,50)
if touches[2] then
local v = touchpt[touches[2]] - touchpt[touches[1]]
if pangle then
pangle = bratan2(v,pangle)
angle = iangle + pangle - sangle
else
pangle = math.atan2(v.y,v.x)
sangle = pangle
iangle = angle
end
end
translate(WIDTH/2,HEIGHT/2)
rotate(math.deg(angle))
sprite(asset.builtin.Tyrian_Remastered.Plane_Boss,0,0)
end
function touched(touch)
if touch.state == ENDED then
touches = {}
touchpt = {}
pangle = false
else
if touch.state == BEGAN then
table.insert(touches,touch.id)
end
touchpt[touch.id] = vec2(touch.x,touch.y)
end
end
function bratan2(v,a)
local b = math.atan2(v.y,v.x)
b = b + math.floor((a - b)/(2*math.pi) + .5)*2*math.pi
return b
end
@dave1707 - neat but I was hoping to reduce the number of digits needed, you’d need three to operate in that way. Could be a good way of twisting gears in a grid system - like one of those solve the puzzle path games.
interesting. still think keyboard would work best. going to try bri's variation next, i think i can plug it in quickly on top of west's, which i have running.
Just for fun, here is a small racetrack to provide a benchmark for evaluating the controls. Time taken to light all the stars and number of collisions with walls might provide metrics to compare and contrast. Very rough and ready and no test of shooting (bullets go through everything).
Marker in the sand: I’m getting around 45s with about 9 bumps to complete the course
The bad part of using a joystick type control is if you swipe thru the middle, the ship changes direction instantly instead of rotating at a given value. For instance, being at the 12 O’clock, sliding down into Go, then to the 6 O’clock position.
@RonJeffries@dave1707 - a little improvement, still not ideal but closer to our need. Probably needs a little tickling on dimensions and could look better with sprites at the expense of screen real estate.
displayMode(FULLSCREEN)
function setup()
--
assert("Please ensure your sound is enabled")
cW,cH = WIDTH/2, HEIGHT/2
angle = -180
padLoc = vec2(100,140)
padSize = 180
goSize = 80
go = false
checkBX, checkBY = 0,0
bpX,bpY,bpS = 172,141,64
butPos = vec3(bpX,bpY,bpS)
-- padCheck = padSize/2
-- goCheck = goSize/2
butCheck = bpS/2
fire = vec4(WIDTH-270,90,240,240)
ship = readImage(asset.builtin.Space_Art.Red_Ship)
trail = readImage(asset.builtin.Tyrian_Remastered.Flame_1)
end
function draw()
--
background(40, 40, 50)
pad()
pushMatrix()
translate(cW,cH)
rotate(angle+90)
if go == true then
sprite(trail,-0,-60,-20)
end
sprite(ship,0,0)
rotate(90)
popMatrix()
rectMode(CORNER)
noFill()
stroke(254, 63)
rect(fire.x,fire.y,fire.z,fire.a)
end
function touched(touch)
--
checkBX = math.abs(butPos.x - touch.pos.x)
checkBY = math.abs(butPos.y - touch.pos.y)
if touch.state == CHANGED then
if math.abs(touch.pos.x - padLoc.x) < butCheck and
math.abs(touch.pos.y - padLoc.y) < butCheck then
print(touch.pos.x - padLoc.x)
go = true
else
go = false
end
if checkBX > 0 and checkBX < 160 then
if checkBY > 0 and checkBY < 160 then
angle=math.deg(math.atan2(padLoc.y-touch.pos.y,padLoc.x-touch.pos.x))
end
end
end
if touch.state == ENDED then
if isInside(touch.pos) == true then
sound(SOUND_SHOOT, 0.5)
end
go = false
end
end
function pad()
--
strokeWidth(2)
stroke(255, 109)
noFill()
ellipseMode(CENTER)
-- ellipse(padLoc.x,padLoc.y,padSize)
ellipse(padLoc.x,padLoc.y,goSize)
pushMatrix()
translate(padLoc.x,padLoc.y)
rotate(angle)
ellipseMode(CENTER)
-- sprite(asset.builtin.Space_Art.UFO ,padLoc.x-170,0,32)
ellipse(padLoc.x-170,0,butPos.z)
popMatrix()
font("AmericanTypewriter-Bold")
fontSize(48)
fill(253, 66)
text("Go",padLoc.x,padLoc.y)
end
function isInside(t)
--
if t.x > fire.x and t.y > fire.y then
if t.x < fire.x+240 and t.y < fire.y+240 then
return true
else
return false
end
end
end
@Bri_G That's a little better, but it still can rotate too fast. What you need to do is limit the rotation speed of the outer circle around the Go circle. That way it can’t rotate too fast but you still have better control over it. I would try to limit it, but it’s your code and I don’t want to step on your toes. I think you’re close to a good solution.
seems like the same idea to me, what am i missing? i share dave's concern about the abrupt change in direction but i think if you make the link indirect the winding won't make sense any more. i could be wrong ...
@dave1707@RonJeffries - thanks for the feedback, I take your point but I think trying to modulate the response would mess it up. The obvious way would be to broaden the inner circle/button thus increasing the circumference. After all, the rotation is dependent upon the user's response speed - if you want fast it can do it, slow - you can do it.
Just thought of another way - make the turn button go through a half, third of the outer circle based at the top. Then apply a variable rate for ship rotation dependent upon extent of movement away from the vertical. Moving the button in the opposite direction would slow down rotation and eventually stop it then reverse it. May take me some time to put that together at the moment - feedback later.
@RonJeffries@Bri_G Here’s a version that eliminates the snap (180 degree) rotation if you slide your finger to the opposite side of the circle.
displayMode(FULLSCREEN)
function setup()
x=150
y=200
x1=x+65
y1=y
ang=0
noFill()
stroke(255)
strokeWidth(2)
end
function draw()
background(0)
ellipse(x,y,200)
ellipse(x1,y1,70)
pushMatrix()
translate(WIDTH/2,HEIGHT/2)
rotate(math.deg(ang)+90)
sprite(asset.builtin.Tyrian_Remastered.Plane_Boss,0,0)
translate()
popMatrix()
end
function touched(t)
if t.state==CHANGED then
if t.x>x1-35 and t.x<x1+35 and t.y>y1-35 and t.y<y1+35 then
ang=math.atan(t.y-y,t.x-x)
x1=math.cos(ang)*65+x
y1=math.sin(ang)*65+y
end
end
end
@dave1707 - cool, you need to format your post in the form thread, I think the ~~~ need a space in there. Could be because you copied my post as I tend to remove free space but there may be some invisible control characters missing if I deleted them.
Also had to add a multiplication sign in the last x1 and y1 lines for it to work.
The response is slower and doesn’t flip but it seems to lose contact occasionally. Thanks for the option I’ll play around with it.
By the way, where does the factor 65 fit in?
Edit: Just noticed the 65 is the x1 offset, but why is it used in the y1 offset later ?
Edit 2: Could you just check copying and pasting your original post (minus the ~~~ ) as I had trouble formatting the posted code in Codea. I tend to indent everything and it didn’t initially indent properly. Again, I think it’s control characters in the forum post that I may have deleted.
@Bri_G Sorry, I had a space before the last ~~~ . I was in a hurry when I posted it and didn’t check it again. Not sure about you’re adding the multiplication signs. The code runs OK as is when I copy and paste it. Losing contact of the small circle was the purpose. That prevents the 180 degree snap and makes you take your time rotating. As for the 65, that’s half the distance between the sizes of the 2 circles (200-70). That keeps the smaller circle touching the larger circle.
@dave1707 - when posted the code originally the multiply sign was omitted on both those lines. Could be a feature of the code formatting in the initial post.
Figured out your disconnect of the turn button from the rotate command. Thanks again.
@RonJeffries@Bri_G Here's another version. Rotate your finger inside the circle in the direction you want the ship to rotate. When you lift your finger, the ship rotation will decrease to a stop. You can change the rotation speed (shipRot) to the speed you want.
PS. The ship rotates at a fixed speed no matter how fast you rotate your finger.
displayMode(FULLSCREEN)
function setup()
xc,yc,radius=150,200,75
screenAng,holdAng=0,0
shipAng=0
shipRot=3
noFill()
stroke(255)
strokeWidth(2)
shipInc=0
end
function draw()
background(0)
ellipse(xc,yc,radius*2)
convert()
pushMatrix()
translate(WIDTH/2,HEIGHT/2)
rotate(shipAng+90)
sprite(asset.builtin.Tyrian_Remastered.Plane_Boss,0,0)
translate()
popMatrix()
end
function touched(t)
if t.state==CHANGED then
turn=inCircle(t.x,t.y,xc,yc,radius)
screenAng=math.deg(math.atan(t.y-yc,t.x-xc))//1
x1=math.cos(math.rad(screenAng))*65+xc
y1=math.sin(math.rad(screenAng))*65+yc
end
if t.state==ENDED then
turn=false
end
end
function convert()
shipInc=shipInc*.95
shipAng=shipAng+shipInc
if turn then
if shipAng>180 then
shipAng=shipAng-360
end
if screenAng>holdAng then
shipInc=shipRot
elseif screenAng<holdAng then
shipInc=-shipRot
end
holdAng=screenAng
end
end
function inCircle(x,y,xc,yc,a)
if (x-xc)^2/a^2+(y-yc)^2/a^2 <= 1 then
return true
end
return false
end
@RonJeffries - Asteroids31 - wow, the control was great and response very good. But, it will give me nightmares, progressed through several levels and it progressively gets very hard, tense!!! Fortunately you have infinite lives.
Suddenly remembered how crap I am when playing games!!
@dave1707 interesting, but jittery. i'm nearly convinced that your sliding idea was as good as any. also i was pleased not to need x1 and y1, as i couldn't figure what they were about.
@RonJeffries The x1,y1 variables were left over from code I removed when I was reworking the code. I was trying a lot of different combinations and didn’t realize I left those in once I got it working the way I wanted. So far with all the different things I tried, I find the up/down sliding for the rotation the easiest to use. I find It has the best control for ship rotation.
@RonJeffries Was looking at your code and noticed the two if dt > 0 statements. Not sure which one shouldn’t be there.
function Targeter:fireDirection()
local dt = self:timeToTarget()
if dt < 0 then return vec2(0,1) end
if dt < 0 then return vec2(1,0):rotate(2*math.pi*math.random()) end
local trueAimPoint = self.target.pos + self.target.step*dt
local relativeAimPoint = trueAimPoint - self.saucer.pos
local offsetAimPoint = relativeAimPoint - dt*self.saucer.step
local dir = offsetAimPoint:normalize()
return dir
end
@RonJeffries - very neat project you finished up with. Notice you moved on to Space Invaders, will watch this one closely as I recently tried to promote a minimal SI game as a communal project. Like the way you return to basics with the machine code versions.
@RonJeffries I was looking at your Space Invaders page where you were showing the hex strings to make the aliens. I thought I’d throw together some code to convert the hex strings into bitmaps/sprites. You can change their size using the parameter slider for the scale command.
displayMode(STANDARD)
function setup()
parameter.integer("sc",1,15,5)
hex1={0x00,0x00,0x39,0x79,0x7A,0x6E,0xEC,0xFA,0xFA,0xEC,0x6E,0x7A,0x79,0x39}
hex2={0x00,0x00,0x00,0x78,0x1D,0xBE,0x6C,0x3C,0x3C,0x3C,0x6C,0xBE,0x1D,0x78}
hex3={0x00,0x00,0x00,0x00,0x19,0x3A,0x6D,0xFA,0xFA,0x6D,0x3A,0x19,0x00,0x00}
hex4={0x00,0x0F,0x1F,0x1F,0x1F,0x1F,0x7F,0xFF,0x7F,0x1F,0x1F,0x1F,0x1F,0x0F}
map1=image(16,8)
map2=image(16,8)
map3=image(16,8)
map4=image(16,8)
bitMap(hex1,map1)
bitMap(hex2,map2)
bitMap(hex3,map3)
bitMap(hex4,map4)
end
function bitMap(hexString,img)
for a=1,#hexString do
for z=0,7 do
if (hexString[a]>>z)&1==1 then
img:set(a,z+1,255,255,255,255)
end
end
end
end
function draw()
background(0)
noSmooth()
fontSize(30)
fill(255)
text("Scale "..sc,WIDTH/2,HEIGHT-100)
scale(sc,sc)
sprite(map1,WIDTH/2/sc,HEIGHT*.7/sc)
sprite(map2,WIDTH/2/sc,HEIGHT*.5/sc)
sprite(map3,WIDTH/2/sc,HEIGHT*.3/sc)
sprite(map4,WIDTH/2/sc,HEIGHT*.1/sc)
end
@RonJeffries Posted the wrong code before. Here’s the correct code. Since the values are 16 bit instead of 8 bit, for my code to work right, every other value needs to be in front of the previous value to create the 16 bit value.
PS. Looked at your article again and noticed you were able to hack the original code.
displayMode(STANDARD)
function setup()
parameter.integer("sc",1,15,5)
hex5={0x0FFF,0x1FFF,0x3FFF,0x7FFF,0xFFFF,0xFFFC,0xFFF8,0xFFF0,0xFFF0,0xFFF0,0xFFF0,
0xFFF0,0xFFF0,0xFFF0,0xFFF8,0xFFFC,0xFFFF,0xFFFF,0x7FFF,0x3FFF,0x1FFF,0x0FFF}
map5=image(22,16)
bitMap(hex5,map5)
end
function bitMap(hexString,img)
for a=1,#hexString do
for z=0,15 do
if (hexString[a]>>z)&1==1 then
img:set(a,z+1,255,255,255,255)
end
end
end
end
function draw()
background(0)
noSmooth()
fontSize(30)
fill(255)
text("Scale "..sc,WIDTH/2,HEIGHT-100)
scale(sc,sc)
sprite(map5,WIDTH/2/sc,HEIGHT*.5/sc)
end
--[[
Original values
1D20: FF 0F FF 1F FF 3F FF 7F FF FF FC FF F8 FF F0 FF F0 FF F0 FF F0 FF
1D36: F0 FF F0 FF F0 FF F8 FF FC FF FF FF FF FF FF 7F FF 3F FF 1F FF 0F
--]]
@RonJeffries Don’t know if you could use this or not. It allows you to resize a sprite/bitMap to whatever size you want. This might allow you to write your Space Invaders without having to use the scale command. It might make the calculations easier not having to account for scaling.
displayMode(FULLSCREEN)
function setup()
size=4
saveName="Invader1"
img=readImage(asset.documents.Dropbox.inv1)
fill(255)
fontSize(20)
newImage=resize(size,img)
saveImage(asset.documents.Dropbox..saveName,newImage)
end
function draw()
background(95, 70, 32)
sprite(img,WIDTH/2,HEIGHT/2+200)
sprite(newImage,WIDTH/2,HEIGHT/2)
text("x 1",100,HEIGHT/2+200)
text("x "..size,100,HEIGHT/2)
end
function resize(size,bitMap)
local iw=bitMap.width
local ih=bitMap.height
local img=image(iw*size,ih*size)
for x=0,iw-1 do
for y=0,ih-1 do
local r,g,b,a=bitMap:get(x+1,y+1)
for x1=1,size do
for y1=1,size do
img:set(x1+x*size,y1+y*size,r,g,b,a)
end
end
end
end
return(img)
end
@RonJeffries I thought I was doing something wrong when I was creating the bitMap of the Shield. I noticed that it’s not symmetrical. The left base is smaller than the right base. The left base is 5 bytes wide while the right base is 6 bytes wide. I’m not sure if that was noticeable in the original game.
Thanks for resize. I think scaling will allow me to do everything in raw historical coordinates 224x256. We'll see. Zip file was named invaders not Invaders, will upload in a moment.
Didn't notice the asymmetry, that's interesting.
Version 10 has the code explicitly. I've not uploaded the images.
I'm not having as much fun as I was with asteroids. Early days tho.
Ha! Bitmap images takes me back. That's how we did fonts in Codea before they implemented text natively. I have a whole library of code for creating sprites for characters using a bitmap font.
@RonJeffries I was looking at you last Space Invaders article about hitting the Shields. I had nothing better to do so I thought I’d try something. Here’s some code I came up with.
displayMode(STANDARD)
function setup()
fill(255,0,0)
rectMode(CENTER)
spriteMode(CENTER)
mx,my=WIDTH//2,-20
vy=0
-- shield sprite is 88 wide, 64 high (4x normal size)
-- shield edges, left, right, bottom, top
shield1=readImage(asset.documents.Dropbox.shield)
sl=WIDTH//2-44
sr=WIDTH//2+44
sb=HEIGHT//2-32
st=HEIGHT//2+32
end
function draw()
background(0)
text("tap around here",WIDTH/2,HEIGHT/2-100)
sprite(shield1,WIDTH//2,HEIGHT//2)
rect(mx,my,10,20) -- missle size 10x20
my=my+vy
tot=0
if mx+5>=sl and mx-5<=sr and my+10>sb and my-10<st then
for x=-5,5 do
xx=(mx-sl+x)//1
yy=(my-sb+10)//1
if xx>=1 and xx<=88 and yy>=1 and yy<=64 then
r,g,b,a=shield1:get(xx,yy)
tot=tot+r+g+b
if tot>0 then
explode()
vy=0
my=-20
end
end
end
end
end
function explode()
for x=-5,5 do
for y=1,10 do
for z=1,20 do
a=math.random(20)
b=math.random(30)
shield1:set((mx-sl+x+a)//1,(my-sb+y+b)//1,0,0,0,0)
end
end
end
end
function touched(t)
if t.state==BEGAN then
vy=1
mx=t.x
my=t.y
end
end
Comments
in other news, i didn't realize mod worked that way. nice.
@RonJeffries - haven’t had much time recently to play, illness in the family, so this has been slow in production. It’s just an example of the controls I posted about earlier, just an idea which combines the power and direction controls for the ship - with a large area for the firing button. Still have some ideas to check but will be a while forthcoming.
One thing, with not having used it for years I struggled to get the sound operating effectively, code below fires up errors so any ideas around that would be appreciated.
I think the controls idea is fairly obvious
i think you'll find that calling collectgarbage is undesirable.
it's an interesting idea, i'm finding it hard to work, but could just be me.larger pad might help me. i agree playing with just thumbs would be good. i might try plugging it in. also maybe make controls easier to modify for experimenters. thanks!
The large catchment area on the right, for fire, is easier to use.
Yes. it's an interesting idea. About the only thing I haven't tried is firing by shouting "FIRE!".
Here’s something I have but I don’t remember exactly who wrote it. Maybe they’ll post and take credit. But you rotate the ship with a thumb and finger on the screen like you’re turning a knob.
@dave1707 - neat but I was hoping to reduce the number of digits needed, you’d need three to operate in that way. Could be a good way of twisting gears in a grid system - like one of those solve the puzzle path games.
interesting. still think keyboard would work best. going to try bri's variation next, i think i can plug it in quickly on top of west's, which i have running.
Just for fun, here is a small racetrack to provide a benchmark for evaluating the controls. Time taken to light all the stars and number of collisions with walls might provide metrics to compare and contrast. Very rough and ready and no test of shooting (bullets go through everything).
Marker in the sand: I’m getting around 45s with about 9 bumps to complete the course
The bad part of using a joystick type control is if you swipe thru the middle, the ship changes direction instantly instead of rotating at a given value. For instance, being at the 12 O’clock, sliding down into Go, then to the 6 O’clock position.
yes, dave ... and it can also happen by accident. it's close to good tho.
@RonJeffries @dave1707 - a little improvement, still not ideal but closer to our need. Probably needs a little tickling on dimensions and could look better with sprites at the expense of screen real estate.
@Bri_G That's a little better, but it still can rotate too fast. What you need to do is limit the rotation speed of the outer circle around the Go circle. That way it can’t rotate too fast but you still have better control over it. I would try to limit it, but it’s your code and I don’t want to step on your toes. I think you’re close to a good solution.
seems like the same idea to me, what am i missing? i share dave's concern about the abrupt change in direction but i think if you make the link indirect the winding won't make sense any more. i could be wrong ...
Just thought of another way - make the turn button go through a half, third of the outer circle based at the top. Then apply a variable rate for ship rotation dependent upon extent of movement away from the vertical. Moving the button in the opposite direction would slow down rotation and eventually stop it then reverse it. May take me some time to put that together at the moment - feedback later.
slider can do that ...
@RonJeffries @Bri_G Here’s a version that eliminates the snap (180 degree) rotation if you slide your finger to the opposite side of the circle.
@dave1707 - cool, you need to format your post in the form thread, I think the ~~~ need a space in there. Could be because you copied my post as I tend to remove free space but there may be some invisible control characters missing if I deleted them.
Also had to add a multiplication sign in the last x1 and y1 lines for it to work.
The response is slower and doesn’t flip but it seems to lose contact occasionally. Thanks for the option I’ll play around with it.
By the way, where does the factor 65 fit in?
Edit: Just noticed the 65 is the x1 offset, but why is it used in the y1 offset later ?
Edit 2: Could you just check copying and pasting your original post (minus the ~~~ ) as I had trouble formatting the posted code in Codea. I tend to indent everything and it didn’t initially indent properly. Again, I think it’s control characters in the forum post that I may have deleted.
@Bri_G Sorry, I had a space before the last ~~~ . I was in a hurry when I posted it and didn’t check it again. Not sure about you’re adding the multiplication signs. The code runs OK as is when I copy and paste it. Losing contact of the small circle was the purpose. That prevents the 180 degree snap and makes you take your time rotating. As for the 65, that’s half the distance between the sizes of the 2 circles (200-70). That keeps the smaller circle touching the larger circle.
Figured out your disconnect of the turn button from the rotate command. Thanks again.
@RonJeffries @Bri_G Here's another version. Rotate your finger inside the circle in the direction you want the ship to rotate. When you lift your finger, the ship rotation will decrease to a stop. You can change the rotation speed (shipRot) to the speed you want.
PS. The ship rotates at a fixed speed no matter how fast you rotate your finger.
@dave1707 - very neat, I like that.
@RonJeffries - Asteroids31 - wow, the control was great and response very good. But, it will give me nightmares, progressed through several levels and it progressively gets very hard, tense!!! Fortunately you have infinite lives.
Suddenly remembered how crap I am when playing games!!
Thank you.
@dave1707 interesting, but jittery. i'm nearly convinced that your sliding idea was as good as any. also i was pleased not to need x1 and y1, as i couldn't figure what they were about.
@RonJeffries The x1,y1 variables were left over from code I removed when I was reworking the code. I was trying a lot of different combinations and didn’t realize I left those in once I got it working the way I wanted. So far with all the different things I tried, I find the up/down sliding for the rotation the easiest to use. I find It has the best control for ship rotation.
@RonJeffries - version 38 crashes on blammo - but not always. Image below showing error report.
yes sorry 39 should be ok
@RonJeffries Was looking at your code and noticed the two if dt > 0 statements. Not sure which one shouldn’t be there.
first one just shoots straight up, put it in for debug, remove it for random shot. thanks!
@RonJeffries - very neat project you finished up with. Notice you moved on to Space Invaders, will watch this one closely as I recently tried to promote a minimal SI game as a communal project. Like the way you return to basics with the machine code versions.
thanks! i think it went well.
@RonJeffries I was looking at your Space Invaders page where you were showing the hex strings to make the aliens. I thought I’d throw together some code to convert the hex strings into bitmaps/sprites. You can change their size using the parameter slider for the scale command.
very nice, thanks!
@RonJeffries I added noSmooth() to the above code in the draw function, so the sprites are sharper as they’re scaled up.
Thanks! I'll be writing about this in just a few minutes.
@dave1707 https://ronjeffries.com/articles/020-invaders/i-03/
Thanks!
@RonJeffries Thanks for the mention in your Space Invaders write up.
thanks for the help!
@RonJeffries Posted the wrong code before. Here’s the correct code. Since the values are 16 bit instead of 8 bit, for my code to work right, every other value needs to be in front of the previous value to create the 16 bit value.
PS. Looked at your article again and noticed you were able to hack the original code.
Yes. For a one-off it seemed the prudent thing to do
@RonJeffries Don’t know if you could use this or not. It allows you to resize a sprite/bitMap to whatever size you want. This might allow you to write your Space Invaders without having to use the scale command. It might make the calculations easier not having to account for scaling.
@RonJeffries I thought I was doing something wrong when I was creating the bitMap of the Shield. I noticed that it’s not symmetrical. The left base is smaller than the right base. The left base is 5 bytes wide while the right base is 6 bytes wide. I’m not sure if that was noticeable in the original game.
@RonJeffries The latest zip file you show for Space Invaders 9 takes me to an I'm sorry, I can't find that page message.
Thanks for resize. I think scaling will allow me to do everything in raw historical coordinates 224x256. We'll see. Zip file was named invaders not Invaders, will upload in a moment.
Didn't notice the asymmetry, that's interesting.
Version 10 has the code explicitly. I've not uploaded the images.
I'm not having as much fun as I was with asteroids. Early days tho.
Ha! Bitmap images takes me back. That's how we did fonts in Codea before they implemented text natively. I have a whole library of code for creating sprites for characters using a bitmap font.
i almost wish i could blit to an image fast enough to do it that way. almost.
blit predates even that
@RonJeffries I was looking at you last Space Invaders article about hitting the Shields. I had nothing better to do so I thought I’d try something. Here’s some code I came up with.
gives pixel out of bounds message. i'll dig into it later
thanks
ah, you have a different shield image than i.