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 - Halifax
Pages: 1 2 3 [4] 5 6 ... 90
46
« on: May 12, 2009, 11:20:57 pm »
You mean like this?
I don't think it looks all that much better, plus there's no speed increase whatsoever.
Yeah, it's not supposed to look better (as I said in my previous post, it will be of reduced quality). At any rate, are you sure you disabled everything, such as the grayscale interrupt (if you're using one) and your just doing straight one-layer black-and-white for the background with no overhead other than your tilemapper? For some reason I was thinking that you should at least get a minimal decrease in the number of milliseconds it takes to render. Even 1 to 2 milliseconds will increase the FPS by 1 in 6 MHz mode.
47
« on: May 12, 2009, 08:59:09 pm »
Minor update - got the app version running. I've supplied a screenshot, at 6MHz this time for some variety.
Looking good. Just curious, calc84maniac, could you include an option to turn off grayscale so that it just uses the first, or second, sprite used for the grayscale rendering? Of course it will be reduced quality, but it should provide a speed up, correct? Also, I don't know if it's feasible with your current code, an option to turn off the background parallax map fully. It's great graphics, don't get me wrong, but if I were to be seriously playing this game, I would probably disable the background.
48
« on: May 11, 2009, 05:16:55 pm »
Looks great calc84maniac, keep up the good work!
49
« on: May 11, 2009, 08:00:42 am »
Well I played the original, lordofthegeeks, and judging from that this aims to be a very good game for the z80 calculators. Also, just as a note, 83/84+ assembly is the same as 86 assembly, the only thing that differs are the ROM calls and where some memory is placed, etc. You will be able to pick it up easily. Then the only other thing, if I remember correctly, is a screen size difference? At any rate, your plan for the bullets seems quite fine. Also, you could store the active flag right along with the bullet data so that you would have the following: location, direction, and active. I would make the 'active' flag 1 bit in a byte so that maybe you could expand upon it later. (Maybe including flags for such things as super crazy insane bullets or something.  ) But yeah, my general algorithm would be to store it with those three things. Then any time you want to add a new bullet, you iterate over the list looking at the 'active' value (which should be the first byte in the structure so you can easily increment to the location and direction data), and if you find a bullet that is inactive, you simply insert the new bullet there, otherwise nothing is inserted. Then, in your rendering routine, you iterate over the list as well, and any bullets that are active you update by one frame, or however you want to do it. If you would like me to take a look at the code, then feel free to PM. I hope you get this working!
50
« on: May 08, 2009, 03:36:40 pm »
Code size shouldn't be a major factor in judging, but there's probably a point where, even if the program runs decently, where the size is unreasonable. If someone were to submit a 14 kilobyte nibbles game  (even the most extensive ones can probably be done in well under 5kb), then their score should suffer a bit.
Yes, there is a point. But that point is in such a gray area that I believe it shouldn't even be included. In your example, of course, it's obvious that the author may have been negligent, but in other more complex games, where do you draw the line? Simply put, you can't objectify it, thus I don't think it should even be included in the scoring.
51
« on: May 08, 2009, 03:33:52 pm »
Ah, you did your casting that way. I was writing mine in java, so i was a bit lazy and just incremented the ray by .02*Unit Vector every time. Unfortunately that menas it didn't get the exact intersection at the wall, and so both the x offset and the y offset were large enough so that it got confused between the two.
Your way is a lot better, but after programing in TI basic for a while, i was a bit overwhelmed with the speed
"You mean I can cast 300 rays, do 3000 trig functions, increment each ray thousands of times, and still get 60 frames per second!?!?!?"
Yeah, I know what you mean, haha. @DJ_Omnimaga: Very true.
52
« on: May 07, 2009, 01:17:43 am »
well, the trickiest part is finding your offset in the picture in the first place, and then scaling the image (Assuming that your writing this for a TI and you are writing your own scale function)
True, and I did in fact write mine in TI-BASIC. I just threw the 64x64 bitmap data in a compressed list so as to not waste the 9 bytes and allowing me to actually use a list. Then you just treat the list as a 2-dimensional array by using something to the effect of w*y+h. And effectively, all you need is either the x or y offset. It depends specifically on what your orientation is to decide which to use. And that's simple in the fact that, if I recall correctly, you can divide your space from 0 to 2pi into 4 quadrants (not the four standard quadrants though). Once you know the direction your ray is going in, you find the first GRID COLLISION, where it hits the grid, not necessarily a filled in block. Then, since you know the size of your blocks and the slope of the ray, you just increment by the size of your blocks using that slope. This leads to you gaining your offset if a collision occurs, and then using that offset in an image of your choosing. Then it's as simple as using the linear filter I spoke about above. Maybe some people would find that hard, but if you just sit down and put it on paper, I don't believe it is really that difficult.
53
« on: May 07, 2009, 12:54:01 am »
Textures are MUCH harder I wouldn't necessarily say that they are MUCH harder. In fact, if you use a simple linear filter, they are quite easy. You have the following: the height of your wall, and the height of your scanline. Assuming you create textures that are the same size as your wall (e.g. 64x64 if your walls a 64 in height) you just calculate a texture step by doing: step = ( height of wall ) / ( height of scanline ). Now you have your step, and the offset into the texture from your raycast already. So just index into the texture from top to bottom with the step you calculated. At least that's what I did for my raycasting engine, and it working out pretty well.
54
« on: May 03, 2009, 11:18:09 pm »
That looks cool Noah, I'm looking forward to playing this game.
55
« on: May 03, 2009, 03:50:58 pm »
Wow, that's amazing. I could never imagine making a game that long, haha.
56
« on: May 03, 2009, 01:45:52 pm »
I agree, fast map loading means quicker fun! I really can't wait to play this game, it sounds like it should be a blast. About how many hours of gameplay do you expect Illusiat 13 to be?
57
« on: May 02, 2009, 05:31:51 pm »
My concern, though, is what hybrid programs should be forced to compete against ASM and what not. For hybrid games only using an utility such as XCOPY or Resource, this might be unfair since ASM would have a clear advantage on graphic speed or quality
I agree. That may be unfair, and thus I think there should be three categories in fact: BASIC, hybrid-BASIC, and ASM. But ASM is no walk in the park either, so it might balance itself out. In the end, I still think 3 categories would probably be the most fair.
That's true, but one thing we have to keep in mind is $$$ 
Oh yes, I'm quite aware of that. That's why I'm just making suggestions. Maybe one category should just be eliminated...who knows.
58
« on: May 02, 2009, 04:53:57 pm »
My concern, though, is what hybrid programs should be forced to compete against ASM and what not. For hybrid games only using an utility such as XCOPY or Resource, this might be unfair since ASM would have a clear advantage on graphic speed or quality
I agree. That may be unfair, and thus I think there should be three categories in fact: BASIC, hybrid-BASIC, and ASM. But ASM is no walk in the park either, so it might balance itself out. In the end, I still think 3 categories would probably be the most fair.
59
« on: May 02, 2009, 03:40:02 am »
Yeah, it has been a long time no see. I'm glad to see you again though. So if we used 1 ASM utility that only copied archived programs to RAM (Like Resource) to save space, then it would be considered Hybrid? even if EVERYTHING else was Basic?
Yes, that should be considered hybrid. Are you gaining a clear advantage over pure BASIC programs? Yes you are in fact. Pure BASIC programs must fit everything into RAM and still make sure it runs fast.
60
« on: April 30, 2009, 10:51:52 pm »
Well that sounds good DJ_Omnimaga, I like that idea, as well as noahbaby94's idea. Screenshots will be able to help some bit.
Pages: 1 2 3 [4] 5 6 ... 90
|
Show Posts