TDG Development Diary

flash · **Reply #60 on:** August 29, 2009, 09:06:48 am

That is looking so so good HK..

I had a thought about rain..

There is the issue of sprite priority. So, to use the rain will need all the sprites pushed to the arse end of the bank to enable the rain to be infront of the characters. Perhaps not a real problem for C to swap them around when needed though, just a bit more messing about than using a BG scroll.

headkaze · **Reply #61 on:** August 29, 2009, 10:09:15 am

There is a global priority setting that can be used for both sprites and backgrounds (value between 0 and 3) so you can place backgrounds or sprites in front of each other. I believe this overrides oam entry position too. I use it to place the room overlays infront of the characters.

I've just finished adding the watch using rotating sprites (oh soooo much easier!) they look a whole lot better. Anyway I had to change to using sprites because drawing over tiles causes problems when using more than 16 colors. Couldn't be bothered trying to figure out why. Perhaps when using 256 colors each tile can only use 16 colors of 16 palettes. I think that's why anyway.

Going to send off the latest demo to Lobo and SF now. Also did a commit so you can check it out Flash.

flash · **Reply #62 on:** August 29, 2009, 10:19:18 am

I will check the commit soon mate - Lovin' it!

What I meant about the sprites is, sprite 0 is above 1, 1 is above 2, 2 is above 3, etc. So, if you used sprites for the rain, the entry for the sprites would have to be less than the value of the sprites that need to be behind the rain. Though, you do have that priority sort that you use to manipulate the sprites on the Y axis, perhaps this could be modded to push character sprites to higher values to allow rain to use the lower values and apear above other sprites? Unless of course you decide to use a BG for the effect?

I also had a little thought about the fireplace.. If this sits on a selection of tiles, would it be possible to use a fireFX to make a ever changing fire and dump that into the relevent tiles - that would look sweet!

headkaze · **Reply #63 on:** August 29, 2009, 10:40:34 am

I was actually thinking of putting the rain behind the level (where the black part up the top was) but I don't think it will work now the levels are taller. I don't think I'll bother with rain, instead just have a rain audio loop with random thunder effect and flash the room to white using the blend register. Should still look cool.

I'm thinking about adding some other lighting effects so everything is more darker and creepier. Perhaps by having chandeliers hanging from the top of the room causing the room to light up when you're below them and go slightly darker as you move away from them. That could also be done using the blend registers although you only get 15 levels of fading to black. So what would have to happen is there would be a light map that as you scroll under a light it calculates the position drawing a fading triangle under it. Then during vblank use a dmacopy of the whole thing so it writes during hblank the different blend value. Pretty easy to do actually and should look really nice.

For the fireplace and tourches on the wall etc. will probably just be animated by placing frames under the level (like we did for Warhawk's destroyed bases) then just dma them as needed.

Eventually I'm going to have to figure out how events are triggered in the original game. Also need to write down when things happen, who's in the room, what objects start where, which doors start locked or closed etc. The best way to do this I think will be to keep saving snapshots in WinVice and then writing down the time and various details until the big picture starts to unfold.

flash · **Reply #64 on:** August 29, 2009, 11:09:38 am

Sometimes in films, the audio presents more of an impression than the visuals themself.

The lighting effects also sound really good.

I will have to print out the solution and work through it to take notes - I agree that this is going to be the tricky part to try and get all the events working as they should. This is crucial to the game play..

spacefractal · **Reply #65 on:** August 29, 2009, 11:22:59 am

Just tried the demo. The music shound nice, but I guess there should been a longer pause before restart, eventuelly it can been anorying at some points (even music actuelly works great in the game).

Also if you go up of stairway and trying go right, down, up, right to press your self out of the screen, you can go up to the wall. Look in the screenshots and yes it look funny (Seen only happens on that room).

In one of the beed room (think it happens on all roms), if you move top, right. you cant go down again. This is a very minor issue and not effect gameplay.

I like the watch and blend nicely

I do think to create more than one tune and the deatch one?

headkaze · **Reply #66 on:** August 29, 2009, 11:44:04 am

Yeah I've noticed that you can bust out of the colmap's sometimes. I just have to go through and make them a bit more robust.

With the music I think I will have it stop after it finishes (I can already detect when the song finishes). It can be a bit annoying that it repeats so much. Because the original game had no music when you walked in on a murder the sudden "murder organ" sound would scare the shit out of you. I don't think it will have the same effect with the music playing before it. So I think I will cut off the music after it's played through and perhaps bring it back in at certain moments in the game (like whenever you find evidence or something).

It would be nice to have another tune that shares the same instruments so I can just jump position like the death one. It would be nice to have parts of the original in there like the bassline and stuff. Perhaps a tune for when you find evidence?

PS You should change No$GBA colour settings so it looks closer to the real thing (Options->Emualtor Setup->GBA Mode set to VGA (poppy bright)).

spacefractal · **Reply #67 on:** August 29, 2009, 11:54:30 am

The major colmap problem was only in that room I found.

In all other, you only got stuck, but was very easy to get free by just go other way. Its a minor issue, but does not really harm the gameplay yet.

I think I let the music stop after end wth a F00 command internal and do not loop which it does now? I think you are right, it more scary when no music is played until you find a dead body and can been more scary. I havent played C64 version very much in that in mind, but this game look very cool.

I think some Ambience music would been cool without any melody as long with rain and thunders?

I would share the instrument so much as possible, and if I add new one I might only add few samples. I like to share instruments and you got subtunes in same XM to work.

Lobo · **Reply #68 on:** August 29, 2009, 11:42:36 pm

Ok, I've just sent the rest of the gfx to HK so it's officially done. All that's left, of course, is to do any eventual fixes for something that I might have missed and such.

Oh, btw, I've found the picture of the Flash's highschool sweetheart, says 'To Flashy Splashy...Love, Betty'.

Lobo · **Reply #69 on:** August 30, 2009, 04:25:19 am

Oopsie! I knew I forgot something-the game icon so here~

flash · **Reply #70 on:** August 30, 2009, 09:00:49 am

Sweet sweet betty,

Oh, I still remember that wonderful Bread & Butter pudding.

headkaze · **Reply #71 on:** August 30, 2009, 09:48:16 am

As always Lobo comes through with flying colours. It looks absolutely awesome with all the new graphics

(How quick is he too?) I have to take my hat off to you mate, you've done a great job and really done the game justice.

I actually want to try and contact the original author and see if we can get an official blessing and perhaps even an insight into how the events are triggered in the game. Would save a tonne of work. So Sam Manthorpe if you're reading this please contact me!

I have started work on the fx system which is going to be similar to the one I wrote for Warhawk so hopefully will be a little familiar to Flash. It also demonstraes the use of a superclass (ie. CFx) which all other Fx subclasses are based on (Eg. CFxFade). It uses "virtual methods" which are overridded in each effect.

I'm currently working on a lighting routine which looks great but unfortunately conflicts with the fade to black routines between entering and exiting each room. Only one blend register per screen. Bummer. But I have come up with a way of adding fade and keeping the nice lighting effect which I will be implementing later tonight

sverx · **Reply #72 on:** August 30, 2009, 12:29:29 pm

Quote from: headkaze on August 29, 2009, 10:09:15 am

There is a global priority setting that can be used for both sprites and backgrounds (value between 0 and 3) so you can place backgrounds or sprites in front of each other. I believe this overrides oam entry position too. I use it to place the room overlays infront of the characters.

On the GBA it was buggy, but it works perfectly on the DS. Think of OAM priority (2 bits) and entry position (7 bits) as a 9 bits priority order: lower comes to the front and higher goes to the back. BTW if you give some of your sprite priority=1 -to get them behind other sprites- you'll also have them behind backgrounds having priority=0, so you've got to change backgrounds priorities too.

Quote from: headkaze on August 29, 2009, 10:09:15 am

I've just finished adding the watch using rotating sprites (oh soooo much easier!) they look a whole lot better. Anyway I had to change to using sprites because drawing over tiles causes problems when using more than 16 colors. Couldn't be bothered trying to figure out why. Perhaps when using 256 colors each tile can only use 16 colors of 16 palettes. I think that's why anyway.

Didn't get this

... are you using 16 colors or 256 colors tiled background? Because if you're using 256 colors tiled background then there shouldn't be any problem. (Anyway using a rotating sprite is easier, of course!)

Bye!

flash · **Reply #73 on:** August 30, 2009, 12:32:06 pm

Quote from: sverx on August 30, 2009, 12:29:29 pm

Didn't get this ... are you using 16 colors or 256 colors tiled background? Because if you're using 256 colors tiled background then there shouldn't be any problem. (Anyway using a rotating sprite is easier, of course!)

The main thing is by using rotating sprites, it does have the benefit of more detailed hands, and yes.. it is easier.

headkaze · **Reply #74 on:** August 30, 2009, 01:04:04 pm

Quote from: sverx on August 30, 2009, 12:29:29 pm

Didn't get this ... are you using 16 colors or 256 colors tiled background? Because if you're using 256 colors tiled background then there shouldn't be any problem. (Anyway using a rotating sprite is easier, of course!)

I'm not exactly sure what was causing the problem but here is my pixel plotting routine

Code: [Select]

void DrawPixel(int x, int y, int colorIndex)
{
	u16 tileId = *(BG_MAP_RAM_SUB(BG1_MAP_BASE_SUB) + (x / 8) + (y / 8) * 32);
	u16* pTile = BG_TILE_RAM_SUB(BG1_TILE_BASE_SUB) + tileId * 32 + ((x % 8) / 2) + (y % 8) * 4;
	*pTile = ((x % 2) == 0 ? ((*pTile &~ 0xF) | colorIndex) : ((*pTile &~ 0x0F00) | (colorIndex << 8)));
}

BTW I have a question for you. I am using the blend register to add an effect which fades out the top of the screen to black (dma during vblank triggered during hblank using a table). But I also want to be able to alpha blend a couple of sprites into the background. My understanding is that there is only one blend register per screen and that you can't do a fade to black and alpha blend at the same time. Also it would seem that alpha blending sprites would effect them all at once. I would have thought (and hoped) that sprites could be alpha blended individually.

sverx · **Reply #75 on:** August 31, 2009, 08:45:48 am

The routine looks correct (but I've got to double check if the lower byte in the halfword corresponds to the left or to the right pixel in that pair...) ... did you get your pixels 'screwed'?

edit once more: I did that check, your code looks correct (the lower byte in the halfword is the one on the left in that pair, so it's the part to update when X is even...)

About fading and alpha blending... it's true, you can't do both at the same time. So if you use fading on the upper part of the screen, you could do blending on the rest of it, don't know if it fits your needs. And about the sprites: yes, all those who's got the blending flag active have got the same blending amount, there's no 'per sprite' blending, unfortunatly. You could try flickering that flag, you'll have sprites which will 'half blend', then. But, again, I don't know if it fits.

Bye!

edit: sorry: I just realized I didn't read your question well enough (I'm quite a beginner in that foreign language of yours

). You CAN do sprite blending while using fading special effect. At least you should be able to do that, I never tried it because I never used fading effects. What you can't do is alpha blending on backgrounds while fading, and they're even using the very same registers.

sverx · **Reply #76 on:** August 31, 2009, 10:18:46 pm

I was already going to fall asleep this evening, then I found enlightment

Code: [Select]

*pTile = ((x % 2) == 0 ? ((*pTile &~ 0xFF) | colorIndex) : ((*pTile &~ 0xFF00) | (colorIndex << 8)));
I guess it's better now... goodnight!

headkaze · **Reply #77 on:** September 01, 2009, 12:28:26 am

Thanks sverx that fixed it! BTW I think I may end up having to use my pixel routine to draw the watch hands now because to use alpha blended sprites you need to have them in 16 bit color mode. When you use 16 bit color mode you can't rotate sprites

If anyone can come up with a way to keep the rotating sprites and use per sprite alpha blending please let me know. I actually thought I could change color modes after drawing the watch but it didn't work (just got a black screen)

ie. Tried running this during HBLANK

Code: [Select]

if(REG_VCOUNT == 0)
{
	REG_DISPCNT_SUB &= ~DISPLAY_SPRITE_ATTR_MASK;
	REG_DISPCNT_SUB |= SpriteMapping_1D_32;
}
if(REG_VCOUNT == 40)
{
	REG_DISPCNT_SUB &= ~DISPLAY_SPRITE_ATTR_MASK;
	REG_DISPCNT_SUB |= SpriteMapping_Bmp_1D_128;
}

sverx · **Reply #78 on:** September 01, 2009, 07:09:20 am

Quote from: headkaze on September 01, 2009, 12:28:26 am

Thanks sverx that fixed it! BTW I think I may end up having to use my pixel routine to draw the watch hands now because to use alpha blended sprites you need to have them in 16 bit color mode. When you use 16 bit color mode you can't rotate sprites

You can rotate an alpha blending sprite, both at 16 and 256 colors. Try with

Code: [Select]

ATTR0_ROTSCALE | ATTR0_TYPE_BLENDED | ATTR0_COLOR_256for instance. What you can't do is specify the alpha value per sprite, but I guess you don't need that...
(if you're not using libnds defines then check this: http://nocash.emubase.de/gbatek.htm#lcdobjoamattributes )

Ah, there's also an interrupt that gets fired when the raster reaches the horizontal line you set, check "LCD V-Counter Match" here: http://nocash.emubase.de/gbatek.htm#gbainterruptcontrol ... I think it's better than firing an interrupt at each hblank...

edit: now I see what you're trying to do! You're using both bitmap objects (32k color) AND 'ordinary' sprites... well, you can do that even without changing REG_DISPCNT<_SUB> because the bits do not overlap, the mapping of sprites boundary works on bits 4 (1D/2D) and 20 & 21 (memory size/boundary) and the mapping of bitmap objects uses bits 6 (1D/2D) and 22 (memory size/boundary)

headkaze · **Reply #79 on:** September 01, 2009, 11:58:19 am

Actually I discovered after that that it's possible to use tiled sprites along with bitmap sprites so I can now display the characters as bitmap sprites and still have the rotating hand sprites for the watch.

Originally I had all the sprites in 256 colour tile mode, but then I wanted to add a character that is like a ghost in the game. Okay so I need to alpha blend a single sprite without effecting the rest. Then I see the following comment "palette for 16 color sprite or alpha for bmp sprite". So I think okay so I need to have the sprites in bmp mode for the alpha value to work. So I change all the sprites to be bitmap sprites and set the alpha value, and .. nothing. So as I said the only reason I've changed to use bmp sprites is to alpha blend a single sprite out so he looks like a ghost!

sverx · **Reply #80 on:** September 01, 2009, 12:11:39 pm

Quote from: headkaze on September 01, 2009, 11:58:19 am

So I think okay so I need to have the sprites in bmp mode for the alpha value to work.

Wow, all that work because of a comment!

I guess you reverted to normal (256 colors) sprite now, uh?

Anyway there's something you should know: semi-transparent sprites will blend their pixel colors only with backgrounds, not with other sprites. So if your ghost passes before another sprite, you won't see that other 'across' the ghost

... you'll just see the background instead (that's really boring also to me, actually

)
(no$gba fails in accuracy here, it blends sprites towards each other...)

Bye!

headkaze · **Reply #81 on:** September 01, 2009, 12:39:32 pm

No I have it now where I can simply copy over the .grit files and uncomment a few things to get them back into tile mode. So it's no biggie.

So I guess my question now is what does the alpha value mean? Do I need to use bitmap mode for the sprites to alpha blend a single one? How does it work? Does I need to use the blend registers as well (REG_BLDCNT_SUB / REG_BLDALPHA_SUB)?

The bitmap_sprite example in libnds not seem to alpha fade the sprites. It does set an alpha value but nothing alpha blends on hardware or No$ as far as I can see.

Are you ever familiar with the latest libnds?

BTW yes that is me "headspin" over on gbadev.org

sverx · **Reply #82 on:** September 01, 2009, 02:08:45 pm

As I already wrote there too, I never really used bitmap objects, I just did a small example in a tutorial I wrote but there was no alpha blending at all in there.

I used 'normal' sprite (16 and 256 colors) before and I also wrote some code using the blending ones... but now I just realized they're no longer working

... so now the problem is either:
- it stopped working (libnds bug? my code changed?)
- it never worked and I had allucinations...

I'm trying to sort it out.

headkaze · **Reply #83 on:** September 01, 2009, 02:16:38 pm

Thanks again sverx. Sorry about the confusion with having the conversation over two forums, but I posted there to see if I can get any advice from Wintermute or one of the libnds coders (or anyone else who may have an idea).

You know it might be a bug in libnds it's starting to sound like it is.

headkaze · **Reply #84 on:** September 01, 2009, 02:50:37 pm

Okay problem solved! Turns out the bug is in the No$GBA emulator. When I ran this on hardware, not only can I have my fade to black in and out but also alpha blending. Just a few tips for others.

1. You have to turn on alpha blending for REG_BLDCNT (BLEND_ALPHA)
2. You must use bitmap sprites for per sprite alpha blending
3. BLEND_SRC_SPRITE is not required and REG_BLDALPHA is ignored when using bitmap sprites. Use the alpha value for each oam entry instead
4. Overlapping two alpha blended sprites only shows the background
5. You won't see the result in No$ so run it on hardware

sverx · **Reply #85 on:** September 01, 2009, 04:00:22 pm

Quote from: headkaze on September 01, 2009, 02:50:37 pm

You have to turn on alpha blending for REG_BLDCNT (BLEND_ALPHA)

I guess this way every sprite gets semi-transparent, not only those with the flag $:-\$

headkaze · **Reply #86 on:** September 01, 2009, 04:08:26 pm

Quote from: sverx on September 01, 2009, 04:00:22 pm

I guess this way every sprite gets semi-transparent, not only those with the flag $:-\$

Actually it doesn't seem to work that way. From gbatek..

Quote

Semi-Transparent OBJs
OBJs that are defined as 'Semi-Transparent' in OAM memory are always selected as 1st Target (regardless of BLDCNT Bit 4), and are always using Alpha Blending mode (regardless of BLDCNT Bit 6-7).
The BLDCNT register may be used to perform Brightness effects on the OBJ (and/or other BG/BD layers). However, if a semi-transparent OBJ pixel does overlap a 2nd target pixel, then semi-transparency becomes priority, and the brightness effect will not take place (neither on 1st, nor 2nd target).

What I noticed on hardware was that using bitmap sprites the REG_BLDALPHA value is ignored altogether. But you do need to set up REG_BLDCNT with BLEND_ALPHA and the various source / destination flags.

The only problem now as I mentioned on gbadev.org is that the alpha values override my fade in/out of black. But what I can do is use the alpha value during the fade to have them fade in and out of black that way. So I'm quite happy with how things are now

sverx · **Reply #87 on:** September 02, 2009, 07:06:17 am

I did some more tests yesterday evening, and I'm quite confident now I've found how it works.

- You have to set the ATTR0_TYPE_BLENDED in the OAM for the sprite(s) you want to alpha blend
- You have to set in the REG_BLDCNT[_SUB] the flags of the DST backgrounds and/or backdrop you want your sprite(s) to blend with (ex: REG_BLDCNT = BLEND_DST_BG1 | BLEND_DST_BG2 | BLEND_DST_BG0 | BLEND_DST_BACKDROP; )
- You have to set REG_BLDALPHA[_SUB] according to 'how' you would like to 'add' the components.
- You don't need to activate a special effect (ex: BLEND_ALPHA). But you can do it, of course. But you also should be able to use another special effect and still have semi-transparent sprites. (There are some limitations, btw...)
- You don't need to activate BLEND_SRC_SPRITE flag in the REG_BLDCNT[_SUB]. If you do this and if you activate also the BLEND_ALPHA mode then you'll have ALL your sprites blending, not only those marked with ATTR0_TYPE_BLENDED

no$gba fails in showing this behaviour, but it works perfectly on hardware. This morning I tried with some other emulators and I found that iDeaS (I'm using ver. 1.0.3.0) does render that feature correctly. My tests were done with 256 colors sprites, but I believe the effect is the same with 16 color sprites and also with bitmap objects (but in this case I think the value in REG_BLDALPHA will be -partially- ignored)

Hope it helps anyway

[I'm going to post the same on gbadev for reference]

Bye!

headkaze · **Reply #88 on:** September 02, 2009, 03:52:57 pm

You keep saying your tests are with 256 colour sprites. Is it possible to do per sprite alpha blending with 256 color sprites? As far as I could tell you couldn't. It doesn't really effect the game that much but I would prefer to use 256 colour sprites.

sverx · **Reply #89 on:** September 03, 2009, 07:14:02 am

If you mean "specify different alpha values for different sprites"... no, that cannot be done with normal (16 & 256 colors) sprite. But these sprites can be rotated whereas bitmap objects can't...

So if you really need to alpha blend more than 1 sprite at the same time and have them blend with different alpha values, well, you need to use bitmap objects too... (maybe you could use both sprites and bitmap objects... ? )

Didn't all that started because you had that ghost you wanted to make semitransparent? $:-\$