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 - Builderboy
Pages: 1 ... 20 21 [22] 23 24 ... 375
316
« on: March 15, 2012, 03:33:08 pm »
Your problem might be this, your code might be doing things in the wrong order, such as:
Move Player
Update Screen
Move enemies
As you can see, in this example the enemies only get moved *after* the screen is updated, so they will always be 1 frame behind in their animation. Might this be what is happening to you?
317
« on: March 15, 2012, 02:22:27 pm »
Oh can you only do pixel testing on the screen, not on images? In that case the second method I suggested would be one of the only ways
318
« on: March 15, 2012, 02:19:21 pm »
no, you would draw the images at all, they would just be used for determining the type of a pixel.
319
« on: March 15, 2012, 02:16:03 pm »
Then you are quite limited on how you define what type your pixels are. You can either use the multiple image method, which gives you a good speed, or you could store the position and type of all the 'special' pixels, which is likely going to be space efficient, but also quite slow.
320
« on: March 15, 2012, 02:08:49 pm »
Can you store color onto your images?
321
« on: March 15, 2012, 02:05:43 pm »
The only real way to have different types of pixels is to have a different image for each property. The destructible image (often reffered to as a mask) would not be displayed, but instead used to test whether or not a pixel is destructible or not. As you can imagine this can increase your file size by large amounts, which is why people generally use tilemaps.
322
« on: March 15, 2012, 01:43:10 pm »
I could, but I will work on putting more useful things in the limited app space 
323
« on: March 15, 2012, 01:40:10 pm »
Lol I've said it before and I'll say it again, there is no need for real time program sending, because the users don't write programs in real time. You could just as easily send your program to a friend and run it on their calculator
324
« on: March 15, 2012, 01:36:05 pm »
Another disadvantage is the storing of your level data. Since you are not using tiles, your levels become a lot larger to store and display. Plus, you also have to keep in mind the size of your enemies and player when designing them.
325
« on: March 15, 2012, 01:28:09 pm »
I Don't plan on adding either of those first two things, but what is a for/rof?
326
« on: March 15, 2012, 01:41:01 am »
Alright I signed the app, fixed some issues with the Readme, and re-uploaded to the first post! I also cross-posted to Cemetech; time to get people learning Redcode so we can have a multi-community battle! 
327
« on: March 14, 2012, 04:10:46 pm »
It's still an option, but if you are doing vertical or horizontal lines, you might as well use Rect().
328
« on: March 14, 2012, 04:06:59 pm »
You can't. In your original code you only had vertical lines, which I was substituting for a 1 wide rectangle for speed  If the beam is rotated, things become a bit more complicated. Quigibo's solution would work, but I fear for the speed, since you would be doing a tan-1 for every pixel on the screen, which is likely going to be super slow. I imagine there would also be other options involving custom line algorithms and rectangular scan-lines, but this does seem like a tricky problem 
329
« on: March 14, 2012, 12:23:07 pm »
If the beam doesn't need to be rotated, the code posted above should work well (although since the lines are vertical, I think the Rect() command may be faster). Does your flashlight beam need to be rotated? Because that completely changes the challenge
330
« on: March 13, 2012, 09:58:55 pm »
Ah yes It does look like I incorrectly named the last 3 addressing modes, the descriptions are correct though, they refer to the B argument.
Pages: 1 ... 20 21 [22] 23 24 ... 375
|
Show Posts