Page 4 of 4
Re: Graphic layers?
Posted: Fri Jul 10, 2009 1:38 am
by osgeld
I had an apple //e since before i can remember to the mid 90's
I am working with stick os (basic) for 32 bit microcontrollers
And also working out a apple //e game for retro challenge 2k9
I am pretty sure I HATE FREAKIN BASIC!
lua is nice, its like basic but not retarded so i am happy with it
Re: Graphic layers?
Posted: Sun Jul 12, 2009 2:29 am
by Jasoco
Code: Select all
RANDOMIZE TIMER
SCREEN 7
DO
X = 20 * RND + 1
Y = 25 * RND + 1
LOCATE X, Y
PRINT "BASIC's not all bad";
LOOP
Re: Graphic layers?
Posted: Sun Jul 12, 2009 3:09 am
by osgeld
Code: Select all
10 FOR N = 1 TO 500
20 ? "BASIC SUX";
30 NEXT N
RUN
course I have not gotten into the nice luxurious modern basic's, that above is for AS Integer basic which was released in 1977, and stick os is still stuck in the stone age as far as basics go, but its much nicer if when you want to just play around and explore a microcontroller rather than using C and compiling and flashing just to find out you had a boo-boo (and you can only flash these things so many times)
Bout as new as i ever got was qbasic on dos, maybe I should try some new forms of it before stating an opinion of it in the modern world
Re: Graphic layers?
Posted: Mon Jul 13, 2009 3:28 am
by Jasoco
I used QuickBASIC back in the mid 90's when our Windows PC died and I was forced to use our old 286 for a few months. Since all it had was some crappy games and whatever came in DOS I taught myself QBASIC.
Thankfully LÖVE came along to free me from the binds of BASIC.
LÖVE has set me free.
Re: Graphic layers?
Posted: Mon Jul 13, 2009 3:49 am
by osgeld
Jasoco wrote:LÖVE has set me free.
agreed, lua is a great scripting language and love is a great implementation of that language
Re: Graphic layers?
Posted: Wed Jul 29, 2009 12:59 am
by Arthurio
bartbes wrote:For only drawing inside the visual area take a look at love.graphics.setScissor.
I tested that ... setScissor is nice but setScissor + not calling a .draw function at all = much much better performance. So much better in fact that using only setScissor has almost no impact in comparison.
This simple function helps alot:
Code: Select all
camera = {x=0, y=0}
screen = {x1=10, y1=10, x2=790, y2=590}
function inScreen(x, y, w, h)
return x-w+camera.x < screen.x2 and y-h+camera.y < screen.y2 and x+w+camera.x > screen.x1 and y+h+camera.y > screen.y1
end
For really big maps tho ... you really need something like quadtree
http://en.wikipedia.org/wiki/Quadtree . Not sure about performance but I would guess that a binary library might work best. - hmm note to self: interesting project
About using lua for game logic: I think it's perfect tool for the job as long as you don't try to do any big data manipulation with it. My tests showed that about 150 000 calculations per update is the limit for a powerful cpu but that's subjective ofc.
Re: Graphic layers?
Posted: Sat Aug 01, 2009 10:50 am
by Raider
..wait a second.
I haven't read all the topic, but are we wanting pixel access that updates efficiently with a GPU texture?
And efficient copies between ram?
I have code that could be useful. It's in C++; it uses memcpy for between-ram copies and "mark as dirty" tile based synchronization for efficient texture sync. It can paste subimages (GL speak for rectangular selections) or just directly access pixels.
Having figured out the potential hazards and having working code, may I help with this if I can?