PeteD

Please excuse the "beard", it was a joke but turned out it was the only semi decent photo I'd got I think the A8 stuff is the ONLY current stuff I mentioned Pete

Previous post.. hmm, I never actually said a kernel was better than a DLI If you read what I posted I said.. (probably spread across various posts but I presumed it was obvious) IF the X pos moves are within Y character areas (or rather there's a character between them) you can trigger a DLI in it's normal place, change the xpos and then quit. If they aren't then you need something closer to a kernel where you'd trigger the DLI then wait for the correct Y position, change an xpos, maybe wait some more, change xpos. OR you could use a timer to trigger an interrupt at the correct line. There shouldn't be a problem with badlines if there aren't many registers to change and if they're done in the right order. As I KEEP saying, there's no inherent problems with any of the methods or multiple different ones, it's not a problem with the resulting code, it's the fact that some poor bastard has got to write it all in the first place.. Pete

There's not really much difference between the 2. Like I say, there's no inherent problem with moving the Xpos of some PMGs, I'm just thinking about the poor coder who has to handle all these different methods to draw things. Pete

Like I say José, nothing you've come up with is impossible and with LN there's even less going on and smaller sprites, it should be even easier. Pete

It shouldn't be a problem at all, in isolation, and like I said earlier if they happened to be in nice positions there'd be no CPU wasted waiting for the correct line. *edit* Or are you talking as in pixel shifts of the whole sprite? Then yeah, the few that are needed could be done at runtime in enough time I reckon. Pete

I'm not saying you shouldn't come up with methods to do it, the more the better in fact. What I am saying is at the same time to remember that without asking a coder about it you can't presume you've either got a practical method or one that a coder would want to work on, they'll likely have all kinds of constraints that you've never thought of. Not sure what your comment about you and others use G2F has to do with anything? I wasn't saying it was a bad thing to use that, just that you DO use it and then because it does things the way the A8 does it's presumed that's ok for a game.. P.S. Not being funny but I'd answer if I understood exactly what you were asking and what the relevance is? In case you still misunderstand.. None of what is being proposed is impossible and as I've said there are benefits in the long run of having a sprite all in PMGs but please don't dismiss what coders say, especially about the complexity of writing a game like this to begin with when at the moment it's all dreams and mockups. Pete

TG version looks nice

Don't misunderstand me, I'm not talking about once it's running, I'm talking about the poor guy who has to handle all these different things that artists come up with and presume are easy to implement If you've got to write the code for the mixed PF/PM routine then once it's written that's it, you CAN use it for both sprites. If you add to that NO X pos moves then you've got a routine that just draws/masks data into PF/PMs (as I say, you've GOT to write it for your method anyway). So to do it the other way, now whoever has just coded that has to write another routine to handle the Kid sprite all in PMGs with X pos shifts. Add to that getting the data into the different formats in the first place.. I'm more concerned about anyone even thinking of starting to code a game like this when they see extra layers of complexity being added because artists or people coming up with G2F mockups have gone, "look! it can look like this, IF you write all these different routines.." Also don't presume that because you've come up with a method of doing the graphics in G2F that pretty much works that it's the ONLY way to do it Like I say, I've got no problem with people coming up with different ways of doing stuff but it seems the ones most insistent on how it SHOULD be done are the ones who aren't going to have to do all the hard work. Pete

Same here, I use atasm because the syntax is what I'm used to but I wouldn't necessarily say it was better than any other assembler. If you're starting out with 6502 then MADS is probably as good a choice as any but if you're used to a certain syntax (how labels are defined, includes, declarations etc) then there's probably something matching what you're used to. Pete

No, you now have TWO routines with your method. Only one otherwise. You don't need more chars for the background so that's moot. *edit* I suppose you could munge the 2 routines into one big mess of code and call it one but that would only be useful if part of it (say the PMG drawing) could be used for both sprites and I still think you can do it without X pos shifting, at least for one of them so you'd be making one reaaaaaly complex routine instead of 2 complex ones. Pete

Easy, then.. All you have to do now is write the code *edit* btw, I don't think there needs to be any (or much) shifting for the sprites as the X movement can be built into the anims and some anims lock/snap you to an X offset anyway. *another edit* To try to make my points clearer.. Someone has got to code this, it's obviously not going to be you (José) and I doubt anyone else is really up for it, these threads are just fun for coders/artists to imagine ways of doing things but it's usually unlikely anything will come of them. My point is not so much the runtime problems of speed/RAM etc but more that if someone is contemplating coding this then why write two sprite routines when using your method you'd need the more complex one anyway, why not just use that for both? I'm pretty sure you can do both sprites in a mix of PF/PM without any X movements which means you just need to split the sprite data into it's component parts. It'll take more RAM but then I doubt it'll ever fit in 64k anyway. Pete

It's certainly possible, would be really great if the X moves could be kept within characters (vertically) so there'd be no need to waste CPU waiting for the right line (or using a timer). What I'm not liking about this method atm is there still needs to be a mixed PF/PM sprite routine for the enemy guys so now instead of one complex routine there's one complex one and one fairly complex one... Pete

Can you OR 2 Player colours together? Yes the game does need masking else you'd need LOTS of extra data for the "thinner" sprites because he might be walking, running, walking with the sword, doing sword moves, standing under the pillar and trying to jump, etc etc. You can't do all of that with different "shapes". It's mostly a case of a solid vertical chunk taken out of the data but not always. If the widest frames (such as the one above) all fit then cool, it's possibly a way to do it. It would probably need a "kernel" to handle X changes as they're unlikely to be on nice DLI positions but that's no massive problem depending on how much CPU time everything else takes. I think you might find some of the frames have skin colour quite far away from each other and might need an extra missile or something but it looks possible. Question is how do you handle the enemy guys with what's left and also it means having a PMG sprite routine with X changes on DLIs AND a normal software sprite routine with masking AND PMGs with masking AND probably X shifts on DLIs. Could turn out to be fairly nasty to write again. Pete

Now you've got me thinking about line drawing limbs and stuff Pete

Then learn to code

I'm pretty sure the sprites are (or can be) aligned to positions so a lot of the frames don't need multiple shifted copies of themselves. Even if not, who says you need double the pixel accuracy JUST because it's hires? that's going over and above what you'd do anyway so why bother? The way I'd looked at it the memory problem is caused by the fact you can compress a sprite frame then just decompress/draw it if you're just drawing to either hires or PF OR PMG alone, when you start to use PF AND PMG at the same time you either need to have data for both or write code that splits the source data into the 2 forms needed to draw it with masking of both and software sprite masking for the PF stuff. José (I believe) is now talking about PMG only for the main sprite but with X shifts which means more data for those too but it should be a hell of a lot less than a split data method. I'm quite intrigued to see what he's come up with As I say, nothing impossible but it's a pain in the ass and it's the kind of thing that'll make people think twice about even starting code. *EDIT* for typos, and making a bit more sense Pete

Never said it would look good the fact that it's a crap load easier to write though means at least there's more chance of a version ever appearing on A8. I personally wouldn't want to do a hires one but I also wouldn't be upset if someone did and the attitude of "it'll be crap because A8 CAN do better therefore it MUST", probably puts off some devs from coding anything. Pete

PoP could be done on A8 in hires and looking pretty much the same as the Spectrum version. Use PMGs to colour the walls and probably the torches (depends what's on each line) and at least it's not just mono. It'd be waaaaaaay easier to do. Pete

Well, you can say that about any game and the only problem arises when people expect more from their machine than coders have either the skill, time or inclination to handle (or the machine can handle) It's certainly possible to do on A8 and I'm pretty sure you could fit it in RAM all in one go (at least the "game" part of it). What the biggest problem is getting all the colours on screen (combined with keeping the data size down). I wrote a simple compression for the sprite data and drawing that into hardware sprites on the C64 would be simple and you've got the res and the colours to make it look nice. Doing the same on A8 involves some really nasty code that I just couldn't be bothered to even start writing that took that compressed data and split it into char data and pmg data, drew them both onto screen with sprite masking for the char parts and also masking of the background elements (pillars etc) of both char and pmg data. From what I remember of looking through the frames there's pretty much none of that going on so no savings there. I think the easiest route for anyone thinking of coding this is to forget 64k systems, use as much ram as needed on an expanded machine to make it easy to draw the sprites and backgrounds. I've only got a 64k machine but I'm happy to play games on machines they already exist on. If the majority of A8 owners have expanded machines, no problem Pete

The only problem with that is 90% of the anim data is your guy and you probably need about 80-90% of that on every screen (some screens may not have ledges for you to swing off for example). Add to that each level only has 1 bad guy type and you'll need to have him loaded at some point whilst still allowing the main sprite to do most of it's moves and you really won't save a lot of memory at any one point. Pete

This is about the easiest looking USB one I've seen so far. Pete

I just leave it as default (at least what it defaults to for me), MPEG-4, 900kbps, one pass average bitrate, FOURCC XVID (that's just the codec header so doesn't really do anything). When you've uploaded a video to youtube, give it 10 mins or so, it seems to encode in different quality settings starting with low so if you upload then play back you get a pretty bad version. If it's still poor quality try adding &fmt=6 to the end of the url. *edit* Here's an upload with those settings Video Pete

Never really did the BBS thing, I left that to my friend who was part of the C64 cracking/trading groups Talent/Ikari but I did spend frustrating hours uploading my C64 demos onto Compunet on the 1200/75 (yes a whole 75 upstream) modem. It used to kill uploads as well when the server got a certain combination of bytes so you'd have to re-pack the file with a different packer and upload it again (more hours of phone bill). Pete

I used ffdshow with mpeg-4 standard settings and it worked a treat but you'll need a fairly grunty machine to encode at full speed. The problem with uploading full frames is I think youtube freaks out (probably about the file size) and compresses it with some awful bitrate rather than being sensible and realising it's uncompressed frames so it should be able to re-compress to a better quality than something that's already been compressed before uploading. If that makes sense Pete