|
|
Post by damainman69 on Aug 16, 2011 12:22:31 GMT -5
After a lot of math manipulating, I've got my full map showing up! Thanks for the help to those who tried! I was right about the for to next routine. If I only had y = 0 to 27, it would only call up that ammount of tiles from the full map from top to bottom. rendering blank tiles for the rest of the map. I've added xtile to the equasion and it pulls the tiles from the proper x start location instead of the top of the actual tile map. Anyhow, that was a half of a day wasted on math. Time for breakfast and a coffee then on to eliminating the diagonal scrolling from my routine (just haven't added it in yet) and then hopefully jumping and background tile collision - which I have been told is a real treat to work with (sarcasm). After that, the daggers can be added, I need to extend the morning star one or two more sprites and then I'll try an creating my first enemy sprite... I've got a long long way to go  Attachments:
|
|
|
|
Post by damainman69 on Aug 16, 2011 19:13:19 GMT -5
Small bug fix update. Having a hard time getting into the forums... Fixed: screen ripping and junk tiles. Attachments:
|
|
|
|
Post by damainman69 on Aug 16, 2011 20:43:00 GMT -5
Big ass snag #3...
While setting up the collision map ( another dim statement) my game stopped working... I thought wow thats the same problem I had when I was trying to set my second scroll layer up I wonder what the deal is.
So it turns out my level map uses all the system ram... 288x101. I thought this was only setting up the dimensions. 40000bytes roughly gone...
What is the work around here. I know I'm not using a huge map. Compared to most games... infact they are quite small. The routine is only calling the map pieces as needed. The actual tile map is a file that is loaded.
|
|
|
|
Post by sega16 on Aug 16, 2011 21:44:44 GMT -5
Of wow this is such a cool game also instead of using an array use read statments.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 16, 2011 22:21:12 GMT -5
Oops, yeah. sega16 is right. I was using an array due to the way my funky engine works + I like dynamic/changeable terrain. Hidden Zenny coins and destructible Dragon Bosses don't count  The background stops moving vertically at the top and bottom of your map if you go left or right while holding up or down. Maybe you can skip this issue by just not having maps that let the player go all the way top or bottom *shrugs* |
|
|
|
Post by bullis1 on Aug 17, 2011 10:24:49 GMT -5
This is a really nice effort for BEX! I love Black Tiger & played the Atari ST version alot. Here's hoping you can fit in the gameplay without running out of CPU time. Good luck!
As a sidenote, the Atari ST version looks really nice and only uses a 16 colour palette. It may be a good source for ripping some resources. The Amiga version probably is too. They also run on 68k if you want to get really fancy and rip some ASM (probably more trouble than it's worth though).
|
|
|
|
Post by damainman69 on Aug 17, 2011 12:53:16 GMT -5
@ sega16: Yeah one of my all time favourite games! I'm looking into the read statements. Tinkered with code on the train this morning, it seems to be ignoring my readtile statement. I'll look into it more later tonight. @ theloon: I have boundaries set on the map scroll (not on the 2nd layer yet) As the real hardware will crash is a negative tile shows up. Once the controls and collision are in place. You wont come close to the boundaries anymore. Also since i haven't programmed jump yet, and there is no detection to grab a column to climb, the only way I can test scrolling up and down is to allow free roam with the controls It'll be all better soon  @ Bullis1: Thanks, I've run our of vacation time to code so now I'm down to nights and my train ride while I'm on my business trip to Toronto. I remember playing the ST version on an emulator and there was something about it that I didn't like - either it was way too zoomed in or chunky scrolling... I can't remember anymore it's been years. I think both the amiga and st versions zoomed way in on the gfx. I'll check but I'm pretty sure I'm better off porting the arcade gfx. My pallets are a bit off still, but thats no big deal. Now the map is working, I can just take the tiles into photoshop and clean them up and re "bin" them for BEX. Overall I wanted to see what could be done with BEX. So far I can see you can do a lot - I wasn't actually expecting to get as far as I have at this point! The community is great although sometimes cryptic with answers - which I get. I often assume that because someone is in the same field as I am, and maybe even for the same amount of time - that they should know *Everything* I know. But everyone learns at the own pace and differently. If I'm interested enough I can learn in a week what it takes some people a year or more to grasp. I can see so much potential in BEX coding. Shooters especially... could totally pull off r-type on here. All of the games I want to code are semi complex... once Black Tiger is working the way I want it, I might start up ghosts n goblins since it is running on the same engine. Black Tiger is all about going to school for me. I need to know BEX inside and out so I can just pick it up and do whatever I want with it. And Devster... if you ever read this, PLEASE PORT BEX TO NEOGEO/NEO CD!!! Oh the potential there... no more colorless gfx... and my neogeo cd would have a use other than sengoku and mutation nation lol! And thanks again for all the input guys!!! You're awesome |
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 18, 2011 7:33:16 GMT -5
damainman69 - The Neo Geo ( CD ) hardware is actually VERY similar to the MegaDrive .. only better / faster
|
|
|
|
Post by damainman69 on Aug 18, 2011 9:43:47 GMT -5
@ moon: haha, yeah I know! That's why I'm hopeful of a port. How different are the specs exactly? I haven't looked up either set of specs in a long time. I was originally going to port black tiger to the tg16/duo super cdrom2 system because graphically better ports but I find myself too forgetful of my 'c' teachings. I'm also not aware of how far along the huC dev kit made it. Regardless I'm hoping a port to neo hardware wouldnt be asking as much as porting to anything else |
|
|
|
Post by damainman69 on Aug 23, 2011 21:15:48 GMT -5
Another little update with working collision!!! Thanks to Elusive for the help!!! Next on the list - jumping and gravity... eek. I'll struggle with it for awhile before I bother anyone. I thought I already had it but me dude is just sliding on through the floor randomly... Here's the latest build - poke, probe, tease... at least it's still moving foward Attachments:
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 24, 2011 9:23:42 GMT -5
It looks like colliding with solids while on solid ground is working when moving right. Did you notice that when moving right and attacking it's possible to move past the solid wall? To reproduce get a running start and keep hitting right and attack like an angry hyperactive child. Lookin' good man |
|
|
|
Post by damainman69 on Aug 26, 2011 19:42:48 GMT -5
Trying to get this working the way I want it do is making me crazy lol.
So I got my (rough looking) jump working right away, but it's bailing on jumping to a higher tile. So I started thinking what would be the best way to handle this and where should I be putting the detection.
I have it set so when you hit the jump button the counter heads for a count of 20 for goin up and then to 40 to hit the ground (no scrolling here). Dispite adding any tile detection or even ypos detection I'm going through the floor...
the jump routine is in a case. Should the detection be a seperate case number or part of the falling case... I've tried both but it's not working.
I'm still going at it but any hints would help here. I must be overlooking something... like an X intead of a y or something...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 27, 2011 0:45:59 GMT -5
What I'm having to do right now to solve my collision detection problems is to start from scratch. Use a single sprite and a single tile for solids. Get the movement and collision down with as little distraction from other stuff as possible.
If I don't have a solution using this method this weekend I'm gonna drink bitter gourd juice!
|
|
|
|
Post by damainman69 on Aug 27, 2011 10:10:40 GMT -5
With sprite detection to detect where the collision is, could you use spriteposx(spritename)+xx? Xx being the exact number of pixels to the side of the sprite? Then convert it into tile data co ords to crosscheck with tilemap data? I forget if sprites in bex have their co-ord set in the upper left or centered. I'm not using the sprite data for checking collision rather what tile is near the pos on the map where the sprite is. I'm sure at this point for me I need to check sprite pos against map pos... I got a bit further last night though...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 27, 2011 13:11:38 GMT -5
I'm still working on this so I don't have a good answer. What I've seen from others is a strictly software solution. Compare the x/y of the player and the x/y of the monster. Use the sprite size as the endpoints to form a bounding box to check for collisions. So, compare the x,y,x+width,y+height of the player with the monsters same variables.
|
|
