 Previous Messages |
Posted By
Chicken
on 2006-09-08
11:58:21
 |  Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
That's just one cool project  Look how long it took METAL DUST on C64 to be released.
Also, I enjoy(ed) the blog. It's really interesting to follow the development. I just hope you have enough time for regular updates. Hopefully, there'll be something to update 
Btw, as mentioned in "The key choice" you guys have made up your mind about using 4 colors only. Honestly, the test screens with more colors looked awesome to me (not considering the sprite problems, though) I understand the technical arguments for just using 4 colors and yes, the graphics are brilliant already and I think it's the right choice sprite-wise.
However, colors have always been one of the best things in the 264er series. Anyway, I can live with your decision (and I know it helps a lot to make some and stick to them).
Good luck and lots of spare time!
|
|
Posted By
Luca
on 2006-09-07
20:38:36
 | Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Active and slow, as ever.
When Mike will have brand new spare time, we will run like hell, you can bet on it
|
|
Posted By
JamesD
on 2006-09-07
20:01:57
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
So is this project still active or dead?
|
|
Posted By
indi
on 2006-08-06
05:58:51
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I have always intended to use SID for music and TED for effects. One day I might actually get around to adding it - who knows.
The detection routine is pretty quick and actually uses a center + width/height, and since you have to be able to shoot+collide with all baddies it has to be able to deal with 9 boxes anyway - so using them on a single baddie isn't the end of the world.
I can use only one if I want to though since its not confined to the center and shape of the sprite.
|
|
Posted By
jaicen
on 2006-08-05
13:41:11
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Whilst I suspect it would be easier to implement a single detect routine, I very much like the idea of having large baddies you have to shoot a number of times. I think it would introduce a touch of strategy rather than a fire and forget type of gameplay.
With regards to the sound effects, has it been decided on how this is going to work?
I'm all for using the SID for three channels of audio (how about stereo SID ) and the TED for all the sound effects, maybe with extras from one SID channel depending on the situation (ie, end of level baddies). Personally the music is more important to me than SFX, but it would be nice to have both.
I wouldn't at this late stage advocate adding these features, especially as i'm such a newcomer to the scene, these are just my personal views.
|
|
Posted By
indi
on 2006-08-05
10:31:54
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yes, but it depends on how the "parent" system is implemented. I can't remember off hand how Xeo3 is done.
|
|
Posted By
Jaicen
on 2006-08-05
07:20:04
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Does that mean it would be possible (memory permitting) to blow up parts of large enemies, depending on where they're hit? I think it would be cool to blow of a wing and have the rest still coming at you for example.
|
|
Posted By
indi
on 2006-08-05
05:04:26
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
One per sprite. If a baddie is made from multiple sprites, then it gets multiple boxes.
|
|
Posted By
Degauss
on 2006-08-04
18:55:18
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Bounding Box? Just out of curiousity: Is that ONE boundingbox per baddie or MULTIPLE bboxes that make up a region?
|
|
Posted By
Mike
on 2006-08-03
10:15:53
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Actually, its not pixel based, its boun bounding box based. This means you don't have to hit every pixel in the baddie. It also helps make the game far more playable.
Sprite to sprite is BBox.
Player Bul sprite is BBox
Baddie Bul to player is character
Player to background is character.
Player to turret is Part of the background collision.
|
|
Posted By
Luca
on 2006-08-03
07:09:44
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Collision detection will be:
- character based for sprites/background
- pixel precise for sprites/sprites (working as you had been able to see)
|
|
Posted By
Degauss
on 2006-08-03
06:49:55
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
It was the first time i saw XEO3 running. That was REALLY impressive. I chuckled a bit because that automasking-method lets the sprites look like on c64
The things i liked most were:
- the level-design and graphics looked very professional
- theres lots of action going on. enough sprites to keep the shoot-em-up-addict in stress
I wonder how the collision-detection working. Is it only checking if characters overlap or is there a pixel-precise approach?
|
|
Posted By
Mike
on 2006-08-03
06:33:26
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Cool!
Thats the only thing thats possibly stopping me releasing the source right away. I want to do the C64 version , but if I release the souce I think someone else will end up doing it!
|
|
Posted By
Luca
on 2006-08-03
06:01:40
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I had a short 10-15 minutes presentation on big screen, then I answered to tons of question while ppl was try the stuff by themselves on my +4.
All the reactions had been characterised by a certain unbelief I was using a real +4 I had to fight against some "stones in the brains", it had been really funny!
Several C64 users told me that XeO3 is the game they wanna see on a C64 too, due to the hi-standard gfx and the overall quality. They played the demo and found it very smooth. We had a long talking about technical aspects and software sprites in general.
|
|
Posted By
Mike
on 2006-08-02
20:16:18
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
So....come on then! How'd it go!! Was it great...or were folk just shrugging!!
|
|
Posted By
Mike
on 2006-07-31
07:37:44
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
lol.... that you just back then!! hehehehe... I still have a long trip back to go yet.. we had a hellish trip to the US, hope going back is easier!
|
|
Posted By
Luca
on 2006-07-31
01:33:19
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
No, because I was talking behind the machine
But lemme go to bed now, after 16 hours by train, we'll talk about it later...
|
|
Posted By
Mike
on 2006-07-30
22:09:10
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Howd it go then?
get any good pics of you showing it?
|
|
Posted By
Luca
on 2006-07-26
12:10:53
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
27.July in the evening. I'll be connected in the afternoon, while packing some stuff...
|
|
Posted By
Mike
on 2006-07-26
12:09:41
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Not at all!! I'm nice I am! My whip hardly ever has spikes in it!
When do you leave?
|
|
Posted By
Luca
on 2006-07-26
08:47:17
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
LOL!
I wonder about you behind their shoulders with a very long whip...*WHACK*
|
|
Posted By
Mike
on 2006-07-26
08:35:44
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
BAH!! Well....just for that....anyone wanna buy xeo3.org?
It was "just in case"...honest.
You have to remember I work with artists that can hardly switch a computer on!!
|
|
Posted By
Luca
on 2006-07-26
07:47:17
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Do you consider me so ignorant
Ppl ppl all witnesses! That's the way Mike considers meeee!
|
|
Posted By
Mike
on 2006-07-26
07:30:10
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Luca: I'm sure you know this already, but you can reset into the monitor and run it again with "G2800". Id imagine you'll need to run it a couple of times when showing it off as its not "that" long a demo.
|
|
Posted By
Luca
on 2006-07-25
18:20:38
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Thanks for your support pal, we need it. Ever.
|
|
Posted By
PopMilo
on 2006-07-25
18:17:07
| Its alive!!!
I was very pleased to see news on blog, and three at once!
And a playable demo exists! And it will be on arok party!
I am just so sory I can not go to that party... timing is just wrong...
Have fun guys, if I would be there I would cheer for XEO3!
|
|
Posted By
Luca
on 2006-06-26
15:10:10
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Splinder had some problems, little time and it will come back.
|
|
Posted By
PopMilo
on 2006-06-26
14:16:59
| Blog Problems ???
What happened to http://xeo3.splinder.com/ ?
I get "500 - Internal Server Error"...
|
|
Posted By
PopMilo
on 2006-05-25
15:10:59
| Just a letter of support....
Love your work guys!!!
Since I found this renewed info few months ago your webpages (blog and forum) have been in my list of 5 sites "I have to check after breakfast,before lunch, and during supper..."
@Luca - you are doing great job! keep on doing it...
@Mike - good luck with family and coding, hope you have time for both of them !
Cant wait to see source of that sprite system...
|
|
Posted By
Luca
on 2006-05-23
08:47:27
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Eeer, PopMilo, unfortunately I need info too. If you'd read the official (ahah!) WIP Weblog of the project
http://xeo3.splinder.com/
you just know I completed all the first level.
At the moment, Mike Dailly had been kidnapped by real life, family, work and similar stuff We all hope new energy will enter his body, in order to continue the adventure.
Stay with us, pray for us too.
|
|
Posted By
PopMilo
on 2006-05-22
17:31:31
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Whats going on ?
We need info !
This is great project and I would like to hear how is it progressing...
|
|
Posted By
Csabo
on 2006-04-27
09:40:44
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yes it does, good catch. It's commonplace in demos. LAX ($nn),Y would be opcode $B3.
|
|
Posted By
AmiDog
on 2006-04-27
01:33:45
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Does the 7501/8501 support the same illegal opcodes as the 6502? If so, it might be a good idea to use the LAX instruction (LDA + TAX combined) to save 2 cycles in the core of the sprite system.
|
|
Posted By
Luca
on 2006-04-25
15:13:49
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
...even though I was ready to use the darkest color one.
Anyway, while building up this very 1st level, I learnt so much, probably I'll release a book titled "The Zen and the Art of Build SHMUPs".
|
|
Posted By
Csabo
on 2006-04-25
14:16:29
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I personally don't mind. The screen look busy as it is - which is a good thing for a shooter. I think I've said it before that clarity is also important, and without being able to color those characters differently, the seeing "path" may be difficult to the player.
|
|
Posted By
Luca
on 2006-04-25
13:25:46
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Heh, it looks so convincing to me, that sometimes I forget why we dismissed it: no masking for the sprites
|
|
Posted By
Lavina
on 2006-04-25
10:22:48
 | Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
pity. It would add a LOT to the visual.
|
|
Posted By
Luca
on 2006-04-25
06:24:20
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Unfortunately, the noncollidable elements had been canceled from the project
|
|
Posted By
Lavina
on 2006-04-24
03:13:17
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Luca, I was just trying to go through the xeo3 blog, and I think you should keep those dark non collidable backdrop elements... How is the decision about it now?
|
|
Posted By
Luca
on 2006-04-21
11:44:58
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
XeO3 blog refreshed with the complete map of Level1!!
|
|
Posted By
indi
on 2006-02-04
10:51:12
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yes thats what happens, although its even more than that. It only generates the sprite in that rotation when its about to draw it. So if a sprite is animating, and moving, theres a good chance that some frames won't ever be rotated.
Also the cache allows sprites that are used a lot to stay inside the cache, while ones that aren't drift to the top of the list.
So yes. Rotate on demand, but demand is mesured per-rotation and no per-sprite. (i.e. I dont do 4 rotations for a sprite, just the one it needs right now).
Much of this will become clear once the source is released.
|
|
Posted By
Rachy
on 2006-02-04
09:34:15
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
@MikeD
It wasn't exactly come thru (at least for me): do you store prerotated sprites? Is it "dynamic"? (I mean only those are stored which are on the screen actually.) Because if it was not "dynamic" you could save a lot of memory with this. As soon as a sprite is about to show up on the screen you could generate its prerotated states, when it disappears the slots can be free'd. (Yes, it needs a bit managing code, but I guess it wouldn't be as hard to implement, neither it would take much processor time.)
|
|
Posted By
Luca
on 2006-02-03
19:57:57
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Ok, yes, I posted a screenshot on the blog
|
|
Posted By
indi
on 2006-02-03
18:14:01
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
For those following the story so far, I have now been able to increase the number of software sprites from 7 to 10. The player + 9 baddies. All fully masked to the background, and still running at the same speed!
The screen just got a whole lot busyer!! Im sure Luca will do a nice screen shot showing it in action sooner or later
|
|
Posted By
indi
on 2006-02-03
12:16:28
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
You'll probably not notice anything, its just giving more time for extra stuff.
|
|
Posted By
Luca
on 2006-02-03
11:59:27
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
The best half-an-hour coding sesion I'd seen ever!
Hope to see a demo soon.
|
|
Posted By
indi
on 2006-02-03
11:48:30
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yeah, about 1 raster of border time I can believe.... TED is real simple... you could do an ADSR with ted cheaply too... which is what I might do for sound effects...
|
|
Posted By
indi
on 2006-02-03
11:46:24
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yeah I know... thats what I ment by "...I'm going to store all of that...." Meaning I'll have to swap them back and forth. Its never in a critical area so thats not an issue... its just the memory I dont like to lose.
Some good news though.... I have managed to speed up the sprite system. This was coded like a demo. 3x3 chars, no loops, load, and or, store etc... This was fast, but it ment that it was tricky to take advantage of other options.
So... Ive reduced it to a single character with a loop of 9. Now this adds around 7 scanlines, but since its now small, I can now add some special cases. Now I can check to see if the sprite is over a BLANK, and if it is... I can Lda/Sta/iny, rather than the horrible masking.
If you think about it, 90% of the time, a sprite is over a blank area, this means I have shaved of LOTS of CPU time for the average case.
There always the chance that everysprite will be over a background character, in which case it is even more expensive... but this is the big difference with games and demos... you have to weigh the costs, and take whats better over all.
So now, its much smaller, and usually much quicker. And it only took 1/2 hour!
|
|
Posted By
Crown
on 2006-02-03
08:09:00
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Yeah, I put a lot in ZeroPage, But Im going to have to store all of that so I can use the ROM to load levels...which is a kicker..
You can have two zero page areas, one for the game, and one for the time when you access ROM functions. You just make a swap copy when you need to call the ROM. It isn't a performance hit at all, if you use this only for infrequent access to ROM functions like when loading a level.
Actually quite a few C64 to Plus4 conversions use this method.
|
|
Posted By
Luca
on 2006-02-03
07:52:48
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Actually, Britelite/DKD told me he coded a neat TEDsound player that runs at $01 rastertime.
|
|
Posted By
indi
on 2006-02-03
07:36:50
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Complex sound is SID music. Its take a good few scanlines to play that sound, and thats what I term as "complex". "beeps" (like TED sound) is VERY quick.. sid sound with slides, reverb, and all that is much slower.
It has nothing to do with the games management of the sound, just the player itself.
|
|
Posted By
Luca
on 2006-02-03
07:21:22
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
MikeD: what did you mean for "complex sound?". You know, there won't be music+fx management, cause explosion will occur only when the player is shot down, or when the big boss explodes. You also just know that max. rastertime for a SIDwinder composed stuff is $17-$18.
|
|
Posted By
Luca
on 2006-02-03
05:47:32
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Kichy: a very interesting way to play TEDsound conversion! But can I use the precalculated TED stuff for SID too (mmm...guess not), or do I need to (almost) double dedicated memory for the music?
Rachy: as you read on the WIP weblog (at the moment picture server is down, ouch! ), I simply have to avoid too much inner black. And that pretty nice rotating chequered missile, unfortunately, has too many inner black areas.
About all the other limitations you cited, IMO we're at our very minimum in order to have something that makes the player happy :/
MikeD: what about masking player's ship only?
Csabo: omg we asked for this genre of forum posting since years, yay!
|
|
Posted By
indi
on 2006-02-03
05:21:58
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
No, I have an "automask". What this does it to use the pixel data to automatically build a mask for the sprite, This adds 2 instructions to the sprite system but is actually quicker than using a mask that I then have to rotate. But what this means is that because I dont store a mask, you can't then use black as a colour. In effect, you end up with the same effect as the C64's hardware sprites. Helow is the core of the sprite system..
lda (Temp+18),y ; 5
tax ; 2
lda (Temp+2),y ; 5
and MCMAutoMask,x ; 4
ora (Temp+18),y ; 5
sta (Addr),y ; 6
iny ; 2 = 29 (with 7 sprites=14,616 cycles)
So for each byte of the sprite, I lose 6 cycles. This turns out to be a lot less then the combined effect of rotating and storing the actual mask (which I've also tried). Every now and then I look back of the sprite system to see if I can speed it up... no joy yet
Memory: I already do this because the sprites have to be double buffered. The main memory block is a rotation cache for the sprites. Normally in games that draw software sprites, they get stored rotated for speed. However, this drops the number of variations of sprites down a lot. So what I do is to have a rotation cache, and rotate the sprites on demand using a barrel shifter. This does take a hit each time a sprite comes on, but I get a lot more shapes for my memory. a LOT more. So rather than say 40-50 baddie graphics if Im lucky, I get 167 (currently).
Heres the current memory map - although it does change now and then.... sometimes a lot as data is shifted around.
$0800-$17ff 2 Screens
$1800-$27ff Music (4K)
$2800-$5000 Game Code and DATA
$5000-$5fff Game charactermap (double buffered) (4K)
$6000-$7fff Sprite graphics (167 16x16's) (8K)
$8000-$8800 spare....(2K)
$9000-$97ff Game Data (4K)
$9800-$9fff Barrel shifter for sprite caching system (MCM version)
$a000-$a3ff Panel Character Set (95 chars + space)
$a300-$afa7 Level Data-13 screens (7*13 - 3x3=91*13=$49F, 200 3x3 blocks=$708) ($ba7)
$b100-$bfff PATH data... (4k-256 bytes)
$c000-$efeb 141 pre-rotations... ($2feb - 141*87)
$f000-$f578 ScrollBuffer
$f578-$fd00 Spare.... (1.5k)
I have been thinking of using TED sound to allow sound effects as well as SID sound, which would also be a first for a game.... that would be neat. But I'll have to get into that later. Yes, the sound does hurt though, quite a lot. But a game simply isn't finished without it. I would probably be able to get another software sprite on if I didn't have complex sound - but 1 sprite, or great sound.... I prefer the sound.
Theres also very little "non-empty" sections, and the "check" would be way more expensive that just drawing the lot. I also dont want a smaller area... that affects the look, and currently it looks better than any other Plus/4 Shoot-em-up because we're oushing the limits.
Yeah, I put a lot in ZeroPage, But Im going to have to store all of that so I can use the ROM to load levels...which is a kicker..
|
|
Posted By
KiCHY
on 2006-02-03
05:13:12
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
TED music:
I remember I did the following method using SID musics with TED while saving a lot of CPU time:
I converted the freq table of music from SID to TED freqs in design time. And used a very simple TED converter with does nothing with freqs (coz its now precalculated). One important thing with this to work carefully with glides (relative or not, decided by the driver)...
|
|
Posted By
Rachy
on 2006-02-03
04:34:13
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
There is something what I don't exactly understand: you rejected the inner black because there is no masking. But if there is masking then inner black can be applied yet.
Memory and processor time waste: in general there is not much I could suggest.
For memory: I guess you use two screens for double buffering, also probably two charsets. It doesn't seem a lot to me. Probably there are also further data for gfx, such as animation which is copied on demand, but yet again it seems not as much memory to me. So what is it taking so much memory? Implementing some simply packing on map elements? (RLE for example.)
On processor time: you could probably implement your own TED sound player, which can be very-very cheap. (Around 2-3 raster lines.) I know that Luca won't be happy...
Also using the zero map as variables, or even for running code could help, it can be faster because of the simplier addressing.
Getting the scrolling area smaller could also help a lot. The rest of the screen could take up by dashboard and some graphical elements.
With clever limits in the elements of the game you could win a lot. Limiting the number of enemies, bullets, etc.
I don't know how much it could help (if at all), but you might check if wasn't it faster moving only the non-empty part of the screen at scrolling. (Obviously checks might take much time.) With tricky map levels where not as many parts of the screen is occupied it might also help.
And finally 2 frames refresh... It isn't pretty, but yet acceptable, IMO.
For the bgcolor problem: I already suggested that if sprites took only 3 colors (2+black) then it won't collide with the bg colors. But you are absolutely right: it takes much time to scroll the color map too.
|
|
Posted By
indi
on 2006-02-02
13:50:01
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Actually... that came out wrong..."Thats only a little more expensive though." meant that full masking on a bitmap screen is only a little slower than using a character map one.
|
|
Posted By
indi
on 2006-02-02
13:48:55
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
There is full masking of sprites. Its not like (most) other Plus/4 games. These are real software sprites that can go over background and other shapes without the black box around them. Thats only a little more expensive though.
No, the real expense comes with having to copy sections of the screen and then paste them back once your done with them. And the "Bullet" problem too would require me to bitmap render 16 more sprites (small ones but still), and require me to save and replace those areas too.
As to changing things... No, I dont mind making major changes if I can save 1/4 of a frame of raster time - and in fact have done a couple of times, and will do again!
No... the real issue is that although I could do this as a demo, I can't really make a game out of it. Theres too much memory waster on just the screen, and too much CPU time wasted of maintaining it.
But feel free to offer other ideas.... anything to save CPU time or memory Im all for!
|
|
Posted By
Rachy
on 2006-02-02
11:34:50
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
As long as I understood: there is no time for masking, so the sprites must not cover any background except plain black. So restoring it wouldn't be as much of a problem, IMO.
/me wonders: how Mike wants to solve collision check if there is no time for masking...
Maybe it is really too late for changing the scroll and the sprite engines, so go guys, go!
(Csabo: I believe that DNF is done when I already played 'til the end. Not any time before that... )
|
|
Posted By
Degauss
on 2006-02-02
09:38:00
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I think the main point about a bitmap-playfield is:
You surely save some cpu time for scrolling and maybe the plain drawing of the sprites is faster as in character mode, but restoring the graphic-area that has been covered with sprites is so expensive that you are going to loose all those benefits (in my opinion).
Another drawback is that you don't have the possibility to use "Not-Really-Softsprites" for Bullets (or Enemies in Boss-Fights!?) in Bitmap-Mode: You cannot draw a Bullet-Graphic with one STA on the screen. (Like: You can theoretically only have one eigth of Bullets on the Screen - bad for a shoot'em up game )
|
|
Posted By
Csabo
on 2006-02-02
09:30:30
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
My suggestion: make it cool, make it fast and make it pretty! Go XeO3 Team, yay!
While it's a cool discussion, aren't you guys a little too far ahead in development to be changing the engine? You don't want anyother Duke Nukem Forever fiasco, right? (BTW, offtopic, it's in the news today that DNF is in production... after a decade... the incredible times we live in...)
|
|
|
|
Posted By
Luca
on 2006-02-02
07:13:41
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
MikeD the one with the ball and the big shape running in background from left side to right?
I'll do after worktime, gimme an hour yet.
|
|
Posted By
indi
on 2006-02-02
06:29:19
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I have....many times in the past for other things. Its simply not possible if you want to move a lot of objects. Or draw large objects for that matter. Using a character map, I can draw a large character sprite "reasonably" cheaply. You simply can't do this with bitmap screens.
Luca: Can you restore the downloads from xeo3.org so that he can download the old scrolling demo?
Have a look at that and see the size of objects I can through around if I want to. You can't do that in a bitmap screen.
|
|
Posted By
Rachy
on 2006-02-02
04:44:52
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
What are the advantages of bitmap scrolling against the character scrolling:
1. you are not limited to one (or few) charset(s)
2. the scrolling itself can be solved via the hardware addressing, thus all you need to refresh is the new part of the screen, which is: 25*8=200 bytes, while scrolling the whole screen (w/o color data) is: 25*40=1000 bytes.
What are the drawbacks:
1. loss of memory (lotsa, I must admit)
2. the new parts of the screen must be redrawn right at once, cannot be built in the background
3. sprite parts need clearing
4. animation needs refreshing (I guess it needs to be done in the charsets too anyway)
I think it worth considering.
|
|
Posted By
indi
on 2006-02-01
09:00:32
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
I dont have much of an issue with the masking either. It looks better for sure, but when things are moving and animating, its easy to pick out "usually".
But I do think the small touches (shadows...sparkles etc) will add more to the overall scene.
|
|
Posted By
Luca
on 2006-02-01
07:22:07
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Really? The comment form refused to work?  Weird...
Well, I'd understood all the difficulties. The nasty one, anyway, is the leck of a sprite masking: if a sprite would rest more than 1 frame over a so called non collidable object, it may begin to "merge" with it, although a continuous animation could save the day.
(But what about a non continuous animated one?).
Nononono, Mike's right. I'm going to use the dozen chars left for some other backdrop stuff, a couple of 2x2 turrets, saving 4-5 of them for a very little animation here and there on the screen.
Hope I could animate ex-3x2turrets, in order to set free some baddies
|
|
Posted By
indi
on 2006-02-01
07:05:27
| Re: Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Oh! And I dont have any issue with using them as collidable objects.. but you can have "space" where you might "think" you can nip through...
|
|
Posted By
indi
on 2006-02-01
07:02:51
| Xeo3 - Background tiles..... Blog 29/01/2006. (impasse!)
Okay.... for a nicer place to discuss....
(Sorry Luca, I tried on you comment bit, but it didn't want to accept my comments)
Okay... the problem with scrolling colours.
1) LOTS of extra CPU time required.
2) 2 extra full screens required so the scrolling can't be "built up" over the 8 game cycles it takes to scroll a full character. This means 4k exta is lost.
3) Sprite colour clash.
4) If sprites have their own colour, then you have to now save/replace the background colours. More memory + CPU
5) If you use a bitmap scroll (shudder!) you then have to save/replace the whole sprite area as well!
If the game was vertical (1 pixel scroll rather than 2 pixels - MCM).... you "might" get away making it run a "little" slower in order to pull this off (CPU time wise), but memory would still be an issue. If the background tiles had colour and were a very dark gray, then it would work great..... but you'd still get colour clash.
As to the background tiles themselves.
Because of the stars in the background which dont scroll, anything else moving will look like your going to hit it. To stop that the background would either have to scroll slower then the foreground, or not move at all. Neither is really possible with current memory/CPU time. So all you have to work with are the current colours, and I dont think that works well enough.
Drawing behind stopped or at a slower speed means anti-scrolling, slow, or lots of memory needed.
To give you an idea of CPU time, this is whats going on just now....
Punch up screen. 21 lines copied every game cycle. This allows large character sprites to be rendered, 7 software sprites and lots of bullets without any save/replace. Takes a whole Vblank period.
Drawing of the 7 software sprites. Around 1.25 frames.(lots)
This leaves around 200 scan lines for "game code", which isn't much since the area left is the screen area so the CPU is in slow mode.
Assume theres virtually no memory left (almost true)
So... with all this in mind, Im open to suggestions.... feel free to alternatives
|
|
