Welcome,
Guest
. Please
login
or
register
.
Did you miss your
activation email
?
1 Hour
1 Day
1 Week
1 Month
Forever
Login with username, password and session length
Home
About
Team
Rules
Stats
Status
Sitemap
Chat
Downloads
Forum
News
Our Projects
Major Community Projects
Recent Posts
Unread Posts
Replies
Tools
SourceCoder3
Other Things...
Omnimaga Radio
TI-83 Plus ASM File Unsquisher
Z80 Conversion Tools
IES TI File Editor
Free RAM areas
Comprehensive Getkeyr table
URL Shortener
Online Axe Tilemap Editor
Help
Contact Us
Change Request
Report Issue/Bug
Team
Articles
Members
View the memberlist
Search For Members
Buddies
Login
Register
Omnimaga
»
Forum
»
Calculator Community
»
Other Calc-Related Projects and Ideas
»
TI Z80
»
Dev Team for Zelda
« previous
next »
Print
Pages: [
1
]
2
3
Go Down
Author
Topic: Dev Team for Zelda (Read 10574 times)
0 Members and 2 Guests are viewing this topic.
ACagliano
LV8
Addict (Next: 1000)
Posts: 919
Rating: +32/-2
Dev Team for Zelda
«
on:
April 24, 2012, 09:42:39 pm »
Ok, I had a few people helping me out on certain aspects of Zelda, but that was months ago and I have since lost those records. If you were working on something, please let me know. I am going to put together a dev team to help me with aspects of Zelda that I cannot program myself. The entire dev team will be credited for the release of this project.
Below is a list of things that need to be done:
1. Artificial Intelligence
2. Collision*
3. Bullet-like shooting system for hook/longshot and bow
4. Smooth scrolling rendering of greyscale graphics
*Collision: The collision with enemies I'm assuming is part of the AI. As for collision with tiles, I just need a way to convert the pixel by pixel Player movement into a way to check if collision with a tile has occurred. To clarify, the variables PlayerX and PlayerY are in pixels. If someone can tell me how to convert that number into a tile value, I can handle checking for movement onto illegal tiles myself.
Beyond that, there are a few other things that need to be done.
1. Compress map data (I can provide the data here, but the utilities will not run on Mac. Someone may need to run the data and post the compressed here).
2. In game-dialogue. I can handle this.
Logged
Hot_Dog
CoT Emeritus
LV12
Extreme Poster (Next: 5000)
Posts: 3006
Rating: +445/-10
Re: Dev Team for Zelda
«
Reply #1 on:
April 24, 2012, 10:07:02 pm »
I don't fully remember if I offered to #4. If not, I can do it, but it may take some time if you want the grayscale as flickerless as possible.
I can also compress data that you put on the website.
Logged
shmibs
しらす丼
Administrator
LV11
Super Veteran (Next: 3000)
Posts: 2132
Rating: +281/-3
try to be ok, ok?
Re: Dev Team for Zelda
«
Reply #2 on:
April 24, 2012, 10:21:25 pm »
for collisions, just use (<pixel position>+<amount of pixels the screen has scrolled since the last tile change>)/<tile size>+<tile offset to the top/left most tile being displayed on the screen> to find the tile a specific pixel is inside. that means that, in order to find the tile above/to the left of your character you would make pixel position the player's position minus one, and to find below/to the right of it would be player position+player size+1
you can do enemy collisions the same way, storing the player's position somewhere and then checking the enemy position against it. it would use their absolute pixel positions (x,y on the screen+tile offset*tile size), though, and would have to use regions, though, so the check for a contact between the player and an enemy would be:
(player position < enemy position < player position + player size) or (player position < enemy position + enemy size < player position +player size), where the positions are the top/leftmost pixel in the sprite. you don't need to worry about having any <= in there unless you make enemies that move in increments larger than enemy increment+player increment, because link gets knocked back by enemies, so they will never be exactly on top of him.
zelda AI should be simple, as they're mostly just moving in straight lines and turning at random intervals or moving towards the player. bosses may be more difficult, though.
just make bullets a special type of enemy that moves faster and deal with them the same way.
«
Last Edit: April 24, 2012, 10:38:03 pm by shmibs
»
Logged
Xeda112358
they/them
Moderator
LV12
Extreme Poster (Next: 5000)
Posts: 4704
Rating: +719/-6
Calc-u-lator, do doo doo do do do.
Re: Dev Team for Zelda
«
Reply #3 on:
April 24, 2012, 10:24:17 pm »
For pixel-by-pixel collision detection, a gave a few mini tutorials not too long ago that show how to make really detailed hitboxes and whatnot and it is fast. The only issue is that it can eat up RAM, fast
Pretty much what you do is draw all the collision areas on another buffer and pixel test that buffer for collision. Then, on another buffer, you draw any damage areas (areas that you get hurt). This could include moving enemies and whatnot. When you pixel test, if there are any pixels in the damaging buffer that overlap (can be tested with XOR), then you get hurt. So at this point, you will need at least four, 768 byte buffers. 1 for the collision layer, 1 for the damage layer, and 2 for the cover layer (since you are doing grayscale).
This means that you need another tileset for collision and damage masks and that you will need to draw 4 sprites per enemy, but that is still a fast process. What size sprites are you using? I have a pixel-test routine that pixel tests a region of a buffer.
Logged
My pastebin
|
Pokémon Amber
|
Grammer Programming Language
|
BatLib Library
|
Jade Simulator
|
Zeda's Hex Opcodes
|
FileSyst Library
|
CopyProg
|
TPROG
|
GroupRead
|
Lbl Read/Write
|
Z80 Floating Point Routines
(
z80float on GitHub
)|
Z80 Optimized Routines Repository
shmibs
しらす丼
Administrator
LV11
Super Veteran (Next: 3000)
Posts: 2132
Rating: +281/-3
try to be ok, ok?
Re: Dev Team for Zelda
«
Reply #4 on:
April 24, 2012, 10:26:40 pm »
/\that works, too, but means that you would have to draw everything to three buffers instead of two, or even more if you want to have insta-kill tiles, like holes, which could really slow things down.
EDIT: it might be faster to check for enemies that way, though, because all that math can slow things down.
«
Last Edit: April 24, 2012, 10:39:36 pm by shmibs
»
Logged
Xeda112358
they/them
Moderator
LV12
Extreme Poster (Next: 5000)
Posts: 4704
Rating: +719/-6
Calc-u-lator, do doo doo do do do.
Re: Dev Team for Zelda
«
Reply #5 on:
April 24, 2012, 11:02:16 pm »
It seems like the best approach will depend on how many objects are around. For collision detection of static objects, my method will be faster, but for moving enemies, probably shmibs'.
Logged
My pastebin
|
Pokémon Amber
|
Grammer Programming Language
|
BatLib Library
|
Jade Simulator
|
Zeda's Hex Opcodes
|
FileSyst Library
|
CopyProg
|
TPROG
|
GroupRead
|
Lbl Read/Write
|
Z80 Floating Point Routines
(
z80float on GitHub
)|
Z80 Optimized Routines Repository
ACagliano
LV8
Addict (Next: 1000)
Posts: 919
Rating: +32/-2
Re: Dev Team for Zelda
«
Reply #6 on:
April 25, 2012, 08:51:28 am »
Well, the method I use to determine if you have moved onto an illegal sprite is this...
I have two separate sets of position variables, Player X and Player Y, both 1-byte large, and PriorPosition, 2-bytes large but contains the Prior X and Y.
1. The movement is performed, so for all intents and purposes, your character has actually moved over one tile, regardless of legality.
2. I test the current position against the value of the tile.
3. If the tile value is illegal (one that you can't move on to), I write PriorPosition over PlayerX and Player Y.
4. If the tile value is one that causes damage, then the correct damage flag is set and the damage counter initiated.
Is the method you guys are proposing more efficient, if so, then we should do that, but it is beyond my coding ability. So is AI of any sort
Logged
aeTIos
Nonbinary computing specialist
LV12
Extreme Poster (Next: 5000)
Posts: 3915
Rating: +184/-32
Re: Dev Team for Zelda
«
Reply #7 on:
April 25, 2012, 11:12:36 am »
For the AI you should ask Kerm or Ashbad.
Logged
I'm not a nerd but I pretend:
Xeda112358
they/them
Moderator
LV12
Extreme Poster (Next: 5000)
Posts: 4704
Rating: +719/-6
Calc-u-lator, do doo doo do do do.
Re: Dev Team for Zelda
«
Reply #8 on:
April 25, 2012, 11:37:45 am »
For Zelda AI, it is rather simple.
Player 1 has coordinates (x,y)
Enemy has coordinates (r,s)
Make (r,s) try to occupy the same space as (x,y). In pseudocode:
Code:
[Select]
If X>R
R+1→R
If X<R
R-1→R
If Y>S
S+1→S
If Y<S
S-1→S
I've made games using a similar algorithm. (In TI-BASIC, I used lists to have multiple enemies chasing you).
Logged
My pastebin
|
Pokémon Amber
|
Grammer Programming Language
|
BatLib Library
|
Jade Simulator
|
Zeda's Hex Opcodes
|
FileSyst Library
|
CopyProg
|
TPROG
|
GroupRead
|
Lbl Read/Write
|
Z80 Floating Point Routines
(
z80float on GitHub
)|
Z80 Optimized Routines Repository
Hayleia
Programming Absol
Coder Of Tomorrow
LV12
Extreme Poster (Next: 5000)
Posts: 3367
Rating: +393/-7
Re: Dev Team for Zelda
«
Reply #9 on:
April 25, 2012, 12:19:45 pm »
The problem in that algorithm is that the enemy will not walk straight.
See the attached image, assuming that "you" don't move.
The enemy will follow the black line, not the
bridged
blue one.
«
Last Edit: April 25, 2012, 12:19:55 pm by Hayleia
»
Logged
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.
click here to know where you got your last +1s
Xeda112358
they/them
Moderator
LV12
Extreme Poster (Next: 5000)
Posts: 4704
Rating: +719/-6
Calc-u-lator, do doo doo do do do.
Re: Dev Team for Zelda
«
Reply #10 on:
April 25, 2012, 03:10:51 pm »
Ah, good point >.>
Are you familiar with the bresenham line drawing algorithm? If so, you can follow the same algorithm, except instead of drawing pixels, draw the enemy
Logged
My pastebin
|
Pokémon Amber
|
Grammer Programming Language
|
BatLib Library
|
Jade Simulator
|
Zeda's Hex Opcodes
|
FileSyst Library
|
CopyProg
|
TPROG
|
GroupRead
|
Lbl Read/Write
|
Z80 Floating Point Routines
(
z80float on GitHub
)|
Z80 Optimized Routines Repository
DJ Omnimaga
Clacualters are teh gr33t
CoT Emeritus
LV15
Omnimagician (Next: --)
Posts: 55943
Rating: +3154/-232
CodeWalrus founder & retired Omnimaga founder
Re: Dev Team for Zelda
«
Reply #11 on:
April 25, 2012, 04:08:56 pm »
Do old Zelda games allow enemies to even more in more than 8 directions, though?
Logged
Xeda112358
they/them
Moderator
LV12
Extreme Poster (Next: 5000)
Posts: 4704
Rating: +719/-6
Calc-u-lator, do doo doo do do do.
Re: Dev Team for Zelda
«
Reply #12 on:
April 25, 2012, 04:36:17 pm »
I don't think so, but if they are moving pixel by pixel, they can make it look like it is moving in more directions.
Logged
My pastebin
|
Pokémon Amber
|
Grammer Programming Language
|
BatLib Library
|
Jade Simulator
|
Zeda's Hex Opcodes
|
FileSyst Library
|
CopyProg
|
TPROG
|
GroupRead
|
Lbl Read/Write
|
Z80 Floating Point Routines
(
z80float on GitHub
)|
Z80 Optimized Routines Repository
ACagliano
LV8
Addict (Next: 1000)
Posts: 919
Rating: +32/-2
Re: Dev Team for Zelda
«
Reply #13 on:
April 25, 2012, 05:59:50 pm »
And so this is how my head explodes.
Technically, when moving pixel by pixel, the only legal directions are horizontal and vertical.
Logged
shmibs
しらす丼
Administrator
LV11
Super Veteran (Next: 3000)
Posts: 2132
Rating: +281/-3
try to be ok, ok?
Re: Dev Team for Zelda
«
Reply #14 on:
April 25, 2012, 07:01:56 pm »
if you are basing your enemies on those of the first zelda game, there doesn't have to be any diagonal motion at all except for zora projectiles, which can move in 16 directions and can't change direction once they start. other games are a bit more complicated, though. here are a few quick examples of how enemies move:
Logged
Print
Pages: [
1
]
2
3
Go Up
« previous
next »
Omnimaga
»
Forum
»
Calculator Community
»
Other Calc-Related Projects and Ideas
»
TI Z80
»
Dev Team for Zelda