This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - nemo
Pages: 1 ... 22 23 [24] 25 26 ... 82
346
« on: December 08, 2010, 07:21:29 pm »
first, thx for the quick awnser, second, its a tile map of8-10
so youre saying i need to do pxl-test?
(im new and i dont now how to post code)
[code] *code* [/code] will work like so: i'm code
and no, you do not need to do pxl test. if you want, you can, but that is not tile-based.i'm saying if you have a tilemap like so: 01010101->GDB1
01000001
01000001
01010101
and each tile is 8x8, and your character was at (8,24) and you wanted to check to see if there's at tile beneath him(there is),and your character is 8 pixels tall, you'd do this: 8->X
24->Y
{Y/8*4+(X/8)+GDB1} //returns tile number at pixel position (x,y)
347
« on: December 08, 2010, 07:10:49 pm »
posting your source code will help. basically, you then find pxl you want to test for. divide the x and y positions by 8, and that's the position of the pixel in the tilemap. assuming 8 is your size, that is.
348
« on: December 07, 2010, 10:25:46 pm »
update! this is how the general feel of the room is going to be. this would be the feel of a testing room. all spritework done by yours truly  , even though it takes forever  gems are nearly complete. you can collect them, but there is the occasional glitch, of which i have a hunch to fix. i'm just lazy. oh, and i know it looks like my character might make it up to get that gem. He wont. it's an impossible jump, i'm testing his limits.
349
« on: December 07, 2010, 10:10:39 pm »
for axe it isn't *too* difficult, but takes some getting used it. in fact i think the implementation is so neat and probably fast i use it whenever i make a computer game. basically, you make your screen larger. there are 96x64 pixels on the screen. you can only move a pixel at a time though. you can't move a half of a pixel, which is why realistic physics like gravity are difficult to implement. so, instead of having our Y values range from 0 to 63, we make them range from 0 to (63*256). the 256 is arbitrary, and most widely used for speed reasons. you could have a 16 there. all it denotes is precision. now your Y values, rather than being restricted to a 0-63 and therefore always in align with a pixel, can be 0-16128, allowing you to technically place a sprite at X,23.25 pixels. of course your pt-on commands would be Pt-On(X/256,Y/256) since you can't draw a sprite off screen. but this setup greatly helps dealing with physics. if you understand this but don't understand what calculations you should be doing, i'll point you to Builderboy's tutorial on gravity and velocity, which will help you understand the main idea in BASIC. if you need any further help PM me and i can give a simple gravity program (:
350
« on: December 07, 2010, 08:16:07 pm »
i'm assuming it's by the rays traced. in which case, the ray would trace through a transparent wall as if it weren't there. you'd need two maps. one indicating whether or not you can walk, and on indicating wether or not the ray should be cast for those pixels.
351
« on: December 07, 2010, 08:12:58 pm »
so, no octagon style wall shapes? Or do you mean ceiling parallel to floor?
this would be achieved by textures. i do wonder if transparent walls would be possible though...
352
« on: December 07, 2010, 08:09:07 pm »
just my opinion, but will the curved wall be possible later?(Like hills)
Nope. curves cannot be supported by a raycaster due to their nature. the z-axis is locked. all walls must form a 90 degree angle with the floor.
353
« on: December 07, 2010, 07:25:34 pm »
I understand everything except assigning a size byte to the output file on a compression? How would I do that when the output file could be any size?
i'm pretty sure there's a counter variable in there somewhere... it might be C (i generally use it for counters), so GetCalc("Str#",C*2) may work at the end. if that doesn't work i'll modify it
354
« on: December 07, 2010, 07:23:40 pm »
math * mat * ma * m... m4+a3+t2+h. clearly. this looks interesting.. just looking at it
355
« on: December 07, 2010, 06:45:18 pm »
i did, but i am unsure how to implement it right now. and i don't know how to implement bresenham's line algorithm soo i may have issues
356
« on: December 07, 2010, 06:39:24 pm »
the routines can be found as links in this thread. by yours truly (: but mind you, they can be optimized severely, they were written with axe 2.5 or so.
357
« on: December 07, 2010, 06:35:46 pm »
pt-mask if for when you want to mask sprites. my editor does not output the data to do this. standard level grayscale works like this. you have a buffer pixel and a back buffer pixel. together, they determine what shade of gray is displayed. imagine the first pixels i the buffer and the second is the back buffer. 00 is white, 01 is light gray, 10 is dark gray, 11 is black. in pt mask, 00 is transparent (whatever is behind the sprite is shown), 01 is white, 10 is gray, 11 is black.
358
« on: December 07, 2010, 06:26:35 pm »
Pt-Mask isn't for four level grayscale. you get output from my program. here's what would display the sprite:
/*my program's output*/->Pic1
Repeat getKey(15)
Pt-On(0,0,Pic1)
Pt-On(0,0,Pic1)r
DispGraphrr
End
359
« on: December 06, 2010, 06:25:41 pm »
Weird, I thought I had fixed that bug...>.>
Yeah, the dithered walls are monochrome, though once I move from bit-maps to nibble or byte maps to accommodate different textures/colors and sprites, I might mess around with grayscale since then the backbuffer is free to use. The dithered walls are drawn the way you'd expect them to be drawn, with a simple :For(Var,Start,End)
:If Var+(X^2)^2
:Pxl-On(X,Var)
:End
Also, remember that we're in 15 mhz mode right now, so the speed isn't quite so impressive (although it is still bearable in 6mhz mode)
couldn't that if statement be: If X^2+Var^2
360
« on: December 06, 2010, 10:59:00 am »
Hello, as some of you may know i am making a computer game in java. its name is Juggernaut. it's going to be similar to a cross between zTrumpet's Exodus (level-wise) and Valve's Portal, combining both their storylines.
Juggernaut is a platformer in which you are an alien and you crashed your ship on an unknown planet. the Juggernaut (supreme force on the planet) has taken you hostage. the Juggernaut enjoys watching people go through trials, and so you have a series of rooms similar to zTrumpet's exodus levels. these are the levels where you learn the controls and rules of the game. then, similar to portal, there's a tricky level in which you were meant to die, but if you play it right.. you escape. then the levels get substantially more difficult and soon you escape, only to be confronted by the Juggernaut, who has stuck you in a timed level, where you must think faster than the clock to escape, and end up stealing a ship to go home.
here's a screenshot of the title screen, it's rather dark. the blood drops fall at differing velocities.
a calculator port is possible and would be written in axe, but wouldn't be started until at least february 15th (the deadline for the contest this project is in).
Pages: 1 ... 22 23 [24] 25 26 ... 82
|
Show Posts