Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 You have a point. It might be nice to free up a little more headroom than the original title anyway, to give it somewhat of a feel like the recent console PoP games (that Ico-like nailbiting of making massive, flailing leaps and barely making it) but we'll do some tests and see how everyone feels about it. I have to admit that I have never played any modern incarnations of PoP (I just read a quite negative about the PS2 version at my favourite reviewing website). And probably I am just very conservative, but IMO the original version feels almost 100% realistic. "Flailing(sp?) leaps" sounds a bit like those comic like martial arts movies. But since I am only providing the kernel, it's not solely my decission anyway. We should discuss in which direction we want to go. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 I'd suggest making everything background anyway. Agreed. BTW: The screen is only 30 pixel wide now (+2 pixel from the adjacent screens) You guys might want to start with 12b - it's only 10 screens, and it has every type of player action required in the game at large. But some elements like gates, switches and both deadly traps (I don't know how they are called in English) seem to be missing. On that note, what sort of screen limit do you think we'll be facing total? Every screen should require much less than 100 bytes, so maybe we can do ~100. Probably much more with some compression and map reusage (I am always optimistic ). If an average level has 20 screens, there are no more than 280 of them. Has anybody counted the total number? What do you guys think about 2-player? Unless I'm mistaken, we can have two sprites and a ball, right? It would be pretty incredible if there was a co-op game. Or maybe sort of a race between players - start each screen, and the first person to reach the 'checkpoint' gets a point when the screen scrolls to the next one. Or maybe the players race to grab a sword. First person to get it can then go slash his/her opponent. I don't think we could have the most obvious 2-player game (fencing battles) because of the sprite limitations, but a co-op addition of the game, sans enemies would be really incredible. Never thought about that, I'll leave that decision up to those who have to implement that mode. Quote Link to comment Share on other sites More sharing options...
Tom Posted February 21, 2005 Share Posted February 21, 2005 Btw, it shouldn't be too hard to automate level generation from the original data files. The file format is known, and there are both level editors and prince of persia engines available... Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 Btw, it shouldn't be too hard to automate level generation from the original data files. The file format is known, and there are both level editors and prince of persia engines available... Thanks for pointing out: www.princed.com.ar Quote Link to comment Share on other sites More sharing options...
Tom Posted February 21, 2005 Share Posted February 21, 2005 I could probably also help with level conversion tools... Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 21, 2005 Share Posted February 21, 2005 BTW: @vdub_bobby, I hope you are still there? I'm still here; I have less time for coding/surfing on the weekend. But I think I have at least one more mockup to show...fully asymmetrical, this one Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 I'm still here; I have less time for coding/surfing on the weekend. But I think I have at least one more mockup to show...fully asymmetrical, this one Good, I am waiting to see that mockup. BTW: This is the missing 2.5D variation: Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 21, 2005 Share Posted February 21, 2005 Good, I am waiting to see that mockup. BTW: This is the missing 2.5D variation: Here ya go, then Still using ball for sword, so would require flicker for battles and a little trickery to get it to be the right color. Wouldn't be hard, I don't think. I'll post something about memory restrictions with my kernel in a minute or two. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 21, 2005 Share Posted February 21, 2005 I'll post something about memory restrictions with my kernel in a minute or two. My setup is a lot more ROM-intensive than Thomas'. However, it is a lot less RAM-intensive (I think). Basically, every unique screen would take about a page of data. Figure a page for the kernel code plus 2+ pages for image data for objects ...leaves, conservatively, 10 'screens' per 4k bank. By my rough count, level 1 has about 20 'screens' of which at least two are the same. So you could probably get all of level one in 8K. However, I am using only 40 bytes of RAM, including variables for X and Y coordinates for players 1&2, the ball, and pointers for everything. I am curious to know how much RAM you're using, Thomas And if you still are having issues with players crossing PF bands? Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 However, I am using only 40 bytes of RAM, including variables for X and Y coordinates for players 1&2, the ball, and pointers for everything. I am curious to know how much RAM you're using, Thomas Currently way too much. But I will redesign (and unroll) the kernel. E.g. I currently the kernel consists out of 13 vertical separted areas, which all have their own color. But the colors are repeating every 4 areas, so I could save 9 bytes there (I could save all bytes here, if all levels get the same color). Then I need 4 bytes for each area plus 8 pointers and 2 variables for the vertical position of the two players. With 13 areas this would result into 13*4+3+8+2 = 65 bytes. Finally I can reduce the number of areas/floor by one and save 13 bytes: -> 52 bytes. BTW: How will you handle collapsing platforms and switches? And if you still are having issues with players crossing PF bands? Currently not, but I am still wondering about using some of those valuable cyclec for other stuff, e.g. repostioning between the three floors. That might be used for some nice eye candy. That would require some additional RAM for the pointers and the positions (4 bytes each). Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 21, 2005 Share Posted February 21, 2005 But the colors are repeating every 4 areas, so I could save 9 bytes there (I could save all bytes here, if all levels get the same color). Then I need 4 bytes for each area plus 8 pointers and 2 variables for the vertical position of the two players. With 13 areas this would result into 13*4+3+8+2 = 65 bytes. Finally I can reduce the number of areas/floor by one and save 13 bytes: -> 52 bytes. BTW: How will you handle collapsing platforms and switches? And if you still are having issues with players crossing PF bands? Currently not, but I am still wondering about using some of those valuable cyclec for other stuff, e.g. repostioning between the three floors. That might be used for some nice eye candy. That would require some additional RAM for the pointers and the positions (4 bytes each). I think what you came up with will probably work best. But who knows. I'm having fun, anyway I don't have a real great familiarity with PoP, so maybe someone else who does can clarify things for me (or maybe I should put in some time playing it - but based on my memory of the game, you take your sword out and put it away (and when you take it out, you can't run or jump...I think). So I figured, taking into consideration the limitations of the 2600 joystick as well, that you could have the sword come out automatically when you enter a room with an (alive) enemy and have it be put away automatically when you enter a room with no enemies. If that would work, then you could use the ball for whatever you wanted in rooms with no enemies. So I figured falling platforms/switches would be perfect for the ball, since they are the same color as the floor (i.e., the PF). But maybe that wouldn't work. You could just use the other player, of course, depending on how many objects are on the screen at a time. Speaking of eye candy (repositioning inside the kernel would be REAL pretty here is another screen I mocked up just for fun Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 21, 2005 Share Posted February 21, 2005 I think what you came up with will probably work best. But who knows. Exactly. It's still a bit early to decide. I'm having fun, anyway Me too. I don't have a real great familiarity with PoP, so maybe someone else who does can clarify things for me (or maybe I should put in some time playing it - but based on my memory of the game, you take your sword out and put it away (and when you take it out, you can't run or jump...I think). I think that is right. So I figured, taking into consideration the limitations of the 2600 joystick as well, that you could have the sword come out automatically when you enter a room with an (alive) enemy and have it be put away automatically when you enter a room with no enemies. That's also happening in the original. If that would work, then you could use the ball for whatever you wanted in rooms with no enemies. So I figured falling platforms/switches would be perfect for the ball, since they are the same color as the floor (i.e., the PF). Yes, but you only have on ball, and there are often multiple falling platforms. Speaking of eye candy (repositioning inside the kernel would be REAL pretty here is another screen I mocked up just for fun Looking great. That's something my kernel couldn't do. I suppose we have to wait until we know how much ROM the animations would require and then decide how much ROM we can "waste" for the dungeon. Quote Link to comment Share on other sites More sharing options...
Tom Posted February 22, 2005 Share Posted February 22, 2005 You can also put your sword away by yourself, useful if you want to chicken out (if you're too slow, you'll get stabbed in the back then:). This is done by pressing down during a fight. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 22, 2005 Share Posted February 22, 2005 If that would work, then you could use the ball for whatever you wanted in rooms with no enemies. So I figured falling platforms/switches would be perfect for the ball, since they are the same color as the floor (i.e., the PF). Yes, but you only have on ball, and there are often multiple falling platforms. But the rooms with enemies are generally (always?) devoid of other objects, right? So you could use a ball for one falling platform and the second player for the other. Limits you to two per screen. How many rooms have more than two objects? A handful could probably be worked around (flicker or minor level redesign), more than that and another solution would probably be better. Speaking of eye candy (repositioning inside the kernel would be REAL pretty here is another screen I mocked up just for fun Looking great. That's something my kernel couldn't do. Hmmmm...I figured that room would be something your kernel could handle easily - now I'm curious! I suppose we have to wait until we know how much ROM the animations would require and then decide how much ROM we can "waste" for the dungeon. In my code I am writing the current frame of the prince image to RAM and then using a 'lda (),Y' read to grab it during the kernel - it doesn't really affect the kernel too much, but it means that no matter how many banks of ROM I need for the screen data, the Prince's data only needs to be in one place Of course, that eats up 12 (currently, didn't Adam say the sprites were going to be 16 pixels tall?) bytes of RAM. Without doing that, my kernel is down to about 30 bytes of RAM. What about that room can't your kernel handle? The curves? Quote Link to comment Share on other sites More sharing options...
salstadt Posted February 22, 2005 Author Share Posted February 22, 2005 "You can also put your sword away by yourself, useful if you want to chicken out (if you're too slow, you'll get stabbed in the back then:)." I think that might be difficult if a player approaches an enemy and tilts the stick too far down as they move right, only to disarm themselves in front of an enemy. I'd favor jut having the sword get drawn automatically when an enemy is approached (set either to specific screens, or pproximity to enemy) and then have the prince put it away again when he goes offscreen or kills the guy. You will never need to use the sword when there's no enemy, an you'll never need to put it away when you're in front of one, so why give the player that option at the expense of the controls. I'm all for having the fire button be an 'action button' that jumps, attacks, grabs items, etc. depending on where you are. Cntext sensitivity is what's going to make this game as fluid as possible. - Adam Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 22, 2005 Share Posted February 22, 2005 you'll never need to put it away when you're in front of one Actually you will have to put the sword away when fighting your own shadow. That's the special trick to beat that level. Quote Link to comment Share on other sites More sharing options...
Tom Posted February 22, 2005 Share Posted February 22, 2005 I must say, I can't remember exactly about PoP 1, but in PoP 2 there are indeed situations where you'll decide to run rather than fight. People would need to play the game to actually find out. Quote Link to comment Share on other sites More sharing options...
Tom Posted February 22, 2005 Share Posted February 22, 2005 Oh yes, the shadow...how could I forget. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 22, 2005 Share Posted February 22, 2005 But the rooms with enemies are generally (always?) devoid of other objects, right? More or less. A bit of level redeign might be necessary. Hmmmm...I figured that room would be something your kernel could handle easily - now I'm curious! No, my kernel works exactly opposite to yours. It loads the PF data from RAM, not for every line, but for larger vertical areas. In my code I am writing the current frame of the prince image to RAM and then using a 'lda (),Y' read to grab it during the kernel - it doesn't really affect the kernel too much, but it means that no matter how many banks of ROM I need for the screen data, the Prince's data only needs to be in one place Clever, but the taller the prince get's, the more RAM you need. Plus the RAM for the enemy. Might become a real problem. What about that room can't your kernel handle? The curves? Yup. Maybe I could use ROM pointers instead of RAM for some areas . But then I had to use (ind),y access and need one extra cycle for each load. And each pointer requires two bytes. And it would eat ROM space from the kernel bank. Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 22, 2005 Share Posted February 22, 2005 No, my kernel works exactly opposite to yours. It loads the PF data from RAM, not for every line, but for larger vertical areas. How small a vertical area can it handle? Two lines? Three? In my code I am writing the current frame of the prince image to RAM and then using a 'lda (),Y' read to grab it during the kernel - it doesn't really affect the kernel too much, but it means that no matter how many banks of ROM I need for the screen data, the Prince's data only needs to be in one place Clever, but the taller the prince get's, the more RAM you need. Plus the RAM for the enemy. Might become a real problem. Well, I'm not doing that for the enemy, since I figure that there will be fewer enemy animation frames (he doesn't put his sword away and run/jump/crouch, does he?) And I thought Adam said that he was going to fit all the sprite animation frames into 8x16, so the most I would need is 16 bytes. Yup. Maybe I could use ROM pointers instead of RAM for some areas . But then I had to use (ind),y access and need one extra cycle for each load. And each pointer requires two bytes. And it would eat ROM space from the kernel bank.Yeah, my kernel currently has zero free cycles in it! Those (ind),Y loads are tough to fit in. Speaking of cycles and stuff, is there a faster way to display a variable-height missile/ball than this? lda BallHeight dcp BallY sbc BallHeight sta ENABL ;+14 I've been racking my brains for the last two weeks trying to figure something out Quote Link to comment Share on other sites More sharing options...
vdub_bobby Posted February 22, 2005 Share Posted February 22, 2005 Speaking of cycles and stuff, is there a faster way to display a variable-height missile/ball than this? lda BallHeight dcp BallY sbc BallHeight sta ENABL ;+14 I've been racking my brains for the last two weeks trying to figure something out I think I'll post this in the programming forum. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 22, 2005 Share Posted February 22, 2005 How small a vertical area can it handle? Two lines? Three? Two lines. Well, I'm not doing that for the enemy, since I figure that there will be fewer enemy animation frames (he doesn't put his sword away and run/jump/crouch, does he?) Nope. Speaking of cycles and stuff, is there a faster way to display a variable-height missile/ball than this? lda BallHeight dcp BallY sbc BallHeight sta ENABL ;+14 I've been racking my brains for the last two weeks trying to figure something out I suppose you need that for the sword, right? So how about using the unused bit of the player colors? lda (ptrC0),y sta COLUP0 asl sta ENAM0 ;+5! That might (if the sword is not directly linked 1:1 to an animation) require some extra color tables, but saves a lot of cycles. And if you use adc #$fc instead of asl you can keep the carry set of you need that. Quote Link to comment Share on other sites More sharing options...
Nukey Shay Posted February 22, 2005 Share Posted February 22, 2005 BTW: Would you be interested in helping to finish this project? IIRC that's something you where looking for. Finish it? I didn't even know it was one (besides a demo of what could be) I'll help out any way that I can...but kernal stuff is mostly over my head. Mostly Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted February 22, 2005 Share Posted February 22, 2005 I'll help out any way that I can...but kernal stuff is mostly over my head. That's what I meant. vdub_bobby and/or I do the kernel and some basics and then other people (e.g. salstadt or Nathan for the graphics, you and others for coding etc.) can join the project and help finishing it. Didn't you look for such a project? Interested? Quote Link to comment Share on other sites More sharing options...
Tom Posted February 22, 2005 Share Posted February 22, 2005 Hereby I repeat my offer to help with level generation tools I suppose it's still too early to do much in that direction, though. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
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.