Jump to content
IGNORED

My new Homebrew project, and i need help


Steril707

Recommended Posts

I am in the process of doing something Breakout/Arkanoid Style for the Vectrex as a small diversion from coding for Vec-Fu, and i hacked something together in a few days (check out the attached .bin, but dont use it with ParaJVE, try Mess or a real Vectrex, some weird problem with ParaJVE keeps the objects small, at least on my version)...

 

Now, i am already quite over my cycles, and i need to make a more clever collision checking routine...Which will need divisions other than by 2...And well, i have evaded that since my day one of 6809 asm ....

 

I have seen a thread here about division by 15 (seems to be important for sprite positioning on the 2600) with the help of a table, but i didnt quite get it.

 

Can somebody give me a pointer in the right direction how i can build up my own table, and use it in my game. I need to divide by 23 and 18 btw...

 

Thanks a lot...

BBOMBER.BIN

Edited by Steril707
Link to comment
Share on other sites

... need to make a more clever collision checking routine...Which will need divisions other than by 2...And well, i have evaded that since my day one of 6809 asm ....

 

I have seen a thread here about division by 15 (seems to be important for sprite positioning on the 2600) with the help of a table, but i didnt quite get it.

 

Can somebody give me a pointer in the right direction how i can build up my own table, and use it in my game. I need to divide by 23 and 18 btw...

 

Thanks a lot...

 

Now what I would usually do here is to give you some great routines for multiplying and then show you how you can divide by 23 by multiplying with the reciprocal. Then someone else would come along and ask exactly why you needed a divide by 23 and 18 and then it would be found out that there was a way to avoid them in the first place.

 

So, we can just skip the fast multiply and divide routines for now and talk about why you need the divide routines. ;-)

Link to comment
Share on other sites

... need to make a more clever collision checking routine...Which will need divisions other than by 2...And well, i have evaded that since my day one of 6809 asm ....

 

I have seen a thread here about division by 15 (seems to be important for sprite positioning on the 2600) with the help of a table, but i didnt quite get it.

 

Can somebody give me a pointer in the right direction how i can build up my own table, and use it in my game. I need to divide by 23 and 18 btw...

 

Thanks a lot...

 

Now what I would usually do here is to give you some great routines for multiplying and then show you how you can divide by 23 by multiplying with the reciprocal. Then someone else would come along and ask exactly why you needed a divide by 23 and 18 and then it would be found out that there was a way to avoid them in the first place.

 

So, we can just skip the fast multiply and divide routines for now and talk about why you need the divide routines. ;-)

 

 

hehe, point taken... :)

 

Okay, i will explain... In my current routine, i check every (displayed) brick for having contact with the ball. I take the coordinates out of a table, thus avoiding any multiplications or divisions. This worked very well after a few tweaks, but needless to say, it really eats up cycles like crazy.

 

The obvious idea now would be to see where the ball is, and then check if there are any bricks having a collision with it.

 

For that i need to divide the X position of the ball by 23, because i have 11 bricks, and my screen is (virtually) 256 pixels wide, and 256/11 is 23.11 period ...

after doing the same with the Y position i can compare the new value with my playfield matrix in ramspace, that looks like this

 

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 1,1,1,1,1,1,1,1,1,0,0

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 0,0,1,1,1,1,1,1,1,1,1

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 1,1,1,1,1,1,1,1,1,1,1 (for example)

 

and voila, i see if i have a collision.

 

If there are any ways to do this without a division, i would be glad to hear them..

:)

Link to comment
Share on other sites

If there are any ways to do this without a division, i would be glad to hear them.. :)

 

Sure, just do 16 bricks ;)

 

Well, the fastest solution is a 256 byte lookup table.

2nd fastest is an unrolled cascade of 11 compares.

3rd comes all the math mumbo jumbo... :lol:

 

The lookup table sounds like a fine idea.

 

Thanks... :)

Link to comment
Share on other sites

The lookup table sounds like a fine idea.

 

Since the other divisor is 18, the resulting values are always < 16 for both divisions, so you can pack both values into one single 256 byte table (hi/lo nibble), though for the cost of splitting the value again before accessing it.

 

Sounds reasonable..Seems people from Augsburg and its vicinity are more clever than their reputation suggests ;) ...

Link to comment
Share on other sites

Ah, one more question i have now...

 

I implemented the 256 byte tables, and i get some weird "value hiccups"...Does the byte table have to start at a page boundary when i use indexed adressing, or something like that? My code seems to be okay otherwise...

That depends. If your table access is outside the kernel, then no special considerations are needed. If the table access is inside the kernel, then page-wrapping will take an extra cycle which could muck up your display.

Link to comment
Share on other sites

Ah, one more question i have now...

 

I implemented the 256 byte tables, and i get some weird "value hiccups"...Does the byte table have to start at a page boundary when i use indexed adressing, or something like that? My code seems to be okay otherwise...

That depends. If your table access is outside the kernel, then no special considerations are needed. If the table access is inside the kernel, then page-wrapping will take an extra cycle which could muck up your display.

What kind of processor does the Vectrex have again?

 

EDIT: Nevermind, looked it up myself.

Edited by vdub_bobby
Link to comment
Share on other sites

Ah, one more question i have now...

 

I implemented the 256 byte tables, and i get some weird "value hiccups"...Does the byte table have to start at a page boundary when i use indexed adressing, or something like that? My code seems to be okay otherwise...

That depends. If your table access is outside the kernel, then no special considerations are needed. If the table access is inside the kernel, then page-wrapping will take an extra cycle which could muck up your display.

What kind of processor does the Vectrex have again?

 

EDIT: Nevermind, looked it up myself.

Oh, this is a Vectrex game? Sorry, I didn't read the whole topic. Ignore my comment - it probably is wrong then.

Link to comment
Share on other sites

I know now that the problem was...

 

The offset in the Motorola 6809s indexed mode is signed...so after a value of 127, it just started scooping around somewhere in front of the byte table...

 

I worked around that in using only 127 bytes tall tables, but that means everything runs at half of the precision than before. Well, i hope i can find a walkaround to this somehow..

Link to comment
Share on other sites

I know now that the problem was...

 

The offset in the Motorola 6809s indexed mode is signed...so after a value of 127, it just started scooping around somewhere in front of the byte table...

 

I worked around that in using only 127 bytes tall tables, but that means everything runs at half of the precision than before. Well, i hope i can find a walkaround to this somehow..

Couldn't you just put the label in the middle of the data table...like this:

   .byte 128, 129, 130, 140, 150,...
  .byte ...253, 254, 255
TableLabel
  .byte 0, 1, 2, 3, ...
  .byte 125, 126, 127

 

Won't that work?

 

EDIT: Using DASM syntax for tables and using 0-255 to represent table entries #0 through #255, if that wasn't clear.

Edited by vdub_bobby
Link to comment
Share on other sites

... need to make a more clever collision checking routine...Which will need divisions other than by 2...And well, i have evaded that since my day one of 6809 asm ....

 

I have seen a thread here about division by 15 (seems to be important for sprite positioning on the 2600) with the help of a table, but i didnt quite get it.

 

Can somebody give me a pointer in the right direction how i can build up my own table, and use it in my game. I need to divide by 23 and 18 btw...

 

Thanks a lot...

 

Now what I would usually do here is to give you some great routines for multiplying and then show you how you can divide by 23 by multiplying with the reciprocal. Then someone else would come along and ask exactly why you needed a divide by 23 and 18 and then it would be found out that there was a way to avoid them in the first place.

 

So, we can just skip the fast multiply and divide routines for now and talk about why you need the divide routines. ;-)

 

 

hehe, point taken... :)

 

Okay, i will explain... In my current routine, i check every (displayed) brick for having contact with the ball. I take the coordinates out of a table, thus avoiding any multiplications or divisions. This worked very well after a few tweaks, but needless to say, it really eats up cycles like crazy.

 

The obvious idea now would be to see where the ball is, and then check if there are any bricks having a collision with it.

 

For that i need to divide the X position of the ball by 23, because i have 11 bricks, and my screen is (virtually) 256 pixels wide, and 256/11 is 23.11 period ...

after doing the same with the Y position i can compare the new value with my playfield matrix in ramspace, that looks like this

 

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 1,1,1,1,1,1,1,1,1,0,0

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 0,0,1,1,1,1,1,1,1,1,1

fcb 0,0,0,0,0,0,0,0,0,0,0

fcb 1,1,1,1,1,1,1,1,1,1,1 (for example)

 

and voila, i see if i have a collision.

 

If there are any ways to do this without a division, i would be glad to hear them..

:)

 

Rather than use a table, you can simply track two separate x and y positions for the ball. One is its screen postion, and another is its brick positon.

 

The screen position x and y are just as you have them now with single bytes 0 up to 256.

 

The brick ball positions are 16-bit fixed point decimals. Each time you move the ball xScreen += 1 you do a mirror addition to the brick position xBrick += 27.273 (BTW, I get 256/11 = 23.273)

 

Since the brick count is less than 17 in both directions you can use the 4 uppermost bits for the integer, and the lower 12 bits as the decimal.

for every 1 you add to xScreen, you must add 372 to the the 16-bit xBrick. Subtract the same amount going in the other direction.

 

The upper byte of xBrick shifted 4 right >> 4 yields the x index to the brick map.

 

For each 1 added to yScreen, you would add 256 / 14 bricks = 18.285714 * 16 fixed point adjustment = 293 to the 16-bit yBrick. Divide the upper byte of yBrick by 16 to get the map position.

 

Cheers!

Link to comment
Share on other sites

Just wait until Friday, when the FC Augsburg will stomp the Munich Lions into the ground. Again. :P

i will remind you about this post of yours after next weekend... :D

 

If I were from Munich, I'd rather go hiding under a rock... :grin:

 

Heya! Augsburg won 3:0! Again! :P :lol: :P

 

:x

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

:x

 

Well, the charm of being a Lions fan is getting accustomed to them losing all the time anyway, o i somehow expected this... :D

Edited by Steril707
Link to comment
Share on other sites

@Vdub_Bobby:

 

Nice idea, i could slap my head for not thinking about that myself...

 

@Robert M:

Thats also a nice way of doing things, but i already spent so much time now to get the table approach right...

 

Thanks everybody for all those suggestions.. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...