Jump to content
IGNORED

DEMO - Impossible Mission (not WIP or Game)


rsiddall

Recommended Posts

8 hours ago, rsiddall said:

Actually, I didn't bump the phosphor up (I've got it at 60% where it's been since the get-go).

And 60% is already quite high compared to real hardware. If you develop for these settings, there is a high risk that people will be disappointed when trying to play your game on real hardware.

  • Like 1
Link to comment
Share on other sites

16 minutes ago, Thomas Jentzsch said:

And 60% is already quite high compared to real hardware. If you develop for these settings, there is a high risk that people will be disappointed when trying to play your game on real hardware.

What would you consider a good rule of thumb for the phosphor?

I believe default (if turned on) is 50%. I've dropped the robots to a single sprite just to see if it looks good and reduces flicker further.

Link to comment
Share on other sites

6 minutes ago, rsiddall said:

What would you consider a good rule of thumb for the phosphor?

There is no definite rule, because there are too many parameters involved. Not only the result on the gaming display, but also the result on your development device. E.g. I have one rather slow and one quite fast monitor. For the slow one, 30% seems adequate, but the faster one needs 50%. Also the signal decay is not linear and not even the same for all colors.

 

The best you can do is to avoid flicker if possible. And don't flicker slower than 30Hz for NTSC.

  • Like 2
Link to comment
Share on other sites

The red color doesn't make any difference at all. 

 

I posted a video with multiple displays and comparisons if you need to see it in action.  ? It's a perception thing.

 

The entire screen goes completely blank (and completely gone) before each new frame is scanned out. There is no persistence on screen at all. That's why CRTs have some great motion resolution.

 

There is persistence on screen with modern "sample and hold" displays. However, your eyes are holding the glow of a CRT because of the brightness. 

 

I remember the horrors of legacy LCD screens. This isn't really image persistence on screen.  ?

Link to comment
Share on other sites

32 minutes ago, orange808 said:

I posted a video with multiple displays and comparisons if you need to see it in action.  ? It's a perception thing.

Yes and no. CRTs were around 5ms (compared to 16ms for one frame at 60Hz), so there you are right. But we are trying to reproduce the perception effect on modern monitors. 

 

BTW: This is a cool link which shows the perception "thing": 

https://www.testufo.com/eyetracking#pattern=lines1&speed=0&foreground=ffffff&background=000000

Link to comment
Share on other sites

3 hours ago, Thomas Jentzsch said:

Yes and no. CRTs were around 5ms (compared to 16ms for one frame at 60Hz), so there you are right. But we are trying to reproduce the perception effect on modern monitors. 

 

BTW: This is a cool link which shows the perception "thing": 

https://www.testufo.com/eyetracking#pattern=lines1&speed=0&foreground=ffffff&background=000000

Oh yes, that is a great site. I'd argue that Rajon changed the world with BlurBusters.

 

There was a brief period where younger gamers were completely unaware that they were staring a blurry mess of crap on their bad LCD monitors. Had to smile when a friend's son took a verbal swipe at my "clunky old heavy" CRTs. Equally funny, hearing an honest reaction the motion clarity of NES games on a proper CRT. The kids didn't even know unless they met someone to show them. Fortunately, Rajon found better ways to get the message out and we have some BFI options these days. ?

 

I also have a good friend that mocked me for buying a big heavy expensive CRT monitor after he got a new LCD.  Funny story, he has since retracted his comment. I still have the CRT and maintain that monitor. His crappy blurry LCD is sitting at the bottom of a trash pile at the dump. I actually chose my monitor after seeing his new monitor in action and lying to him about liking it. It was an abomination.

 

As for the effect of a nice bright light on my eye:  I know it's obvious, but the easiest method to experience retinal persistence is looking at a light for an instant and quickly closing your eyes. ?

 

 

Link to comment
Share on other sites

On 5/25/2022 at 11:56 PM, rsiddall said:

Here's a quicktime movie showing the flickering after I've adjusted some of the colors.

I've updated the running, too. I think it's a little more accurate to the original game.

 

 

That's cool!  The original was my favorite game on the C64.

  • Like 1
Link to comment
Share on other sites

Small update. Just a Quicktime movie showing some of the concessions made to reduce the flicker.

Phosphor is now @ 50% (default setting when turned on).  Some cosmetic changes as well as turning off PF0=250 (no tunnel walls) in favor of being able to use pfcolors to create the fireplace and computer stand.

 

It's serviceable I guess...just not what I had hoped for originally. Adjusting the colors to help with flicker would end up with pink robots (easier to see) and not sure how menacing a pink robot would be. ?

Screenshot_20220528-162128.png

Edited by rsiddall
  • Like 3
Link to comment
Share on other sites

On 5/26/2022 at 2:26 PM, orange808 said:

The development experience is going to be similar between all the flavors of bB kernels. Each particular kernel has unique trade-offs, so switching between them will always require a little adjustment, but I can't see why any one kernel would be significantly more intimidating than another.

 

 

Speaking as someone who had started a few years ago and had played around with a few of the kernels, I would say that going from Standard to the others is relatively easy. Each do present different limitations or options but once I got acquainted with some of the quirks I found it okay and I feel rather comfortable using either standard, DPC+, or even Superchip. Sometimes I forget a thing or two and I get momentarily stumped but even then working around such things had sometimes resulted in fun little gameplay elements or discoveries.

  • Like 1
Link to comment
Share on other sites

@rsiddall  The robots in the new update look pretty good to me now, even with some flicker!  However, the flicker at the computer stand is quite noticeable.  Is it feasible to hide the stand when the player is right in front of it searching?  Also, the player's nose is looking very, how should I say?, prominent.  I know the original sprite had a bit of nose, but since in you need to make the character in lower-resolution, I wonder if it would be better without that pixel?

  • Like 1
Link to comment
Share on other sites

Sorry...asleep early last night. Here are a few screenshots without the nose and additional playfield furniture.

The stereo on 3rd floor has a byproduct of the missile "turning" on when the running man is on that floor.

 

In the photos, first one is "off" / black. Second one is "on" / white. Wasn't intentional, but kinda neat just the same.

Third photos shows "searching" with the pedestal removed and computer now sitting on a shelf of sorts.

New1.png

New2.png

New3.png

  • Like 4
Link to comment
Share on other sites

Well, another update and a host of problems...

I can make it look great in the QT movies because I'm in control of the character.

 

Playfield objects are a problem when jumping because of the fake gravity (ability to fall).

I added 4-lives but really should consider a timer (like Pitfall's 20 minutes) since jumping the robots will eat your lives up quickly if you connect with them.

 

Anyhoo...

  • Like 3
Link to comment
Share on other sites

7 hours ago, ZeroPage Homebrew said:

The jumping and the new objects on the screen look awesome, great use of the playfield for the larger ones!

 

- James

Agreed!  It's really starting to feel like the original versions in overall effect.

  • Like 1
Link to comment
Share on other sites

On 5/31/2022 at 3:14 PM, rsiddall said:

Well, another update and a host of problems...

I can make it look great in the QT movies because I'm in control of the character.

 

Playfield objects are a problem when jumping because of the fake gravity (ability to fall).

I added 4-lives but really should consider a timer (like Pitfall's 20 minutes) since jumping the robots will eat your lives up quickly if you connect with them.

 

Anyhoo...

It looks like a promising port is possible.
There is a lot of work ahead of you!
Do you plan to publish the source code?

 

 

  • Like 2
Link to comment
Share on other sites

I haven't included source code previously but in this particular case I have a feeling what I am capable of will limit progression and ultimately the game, itself. I've already run into some problems that I'm not sure can be remedied (at least by me) or I haven't found an answer.

 

1. I'd like to include a countdown timer. I know it's possible in the standard kernel, but I haven't been able to find an example of one (like Pitfall) where it works in DPC+. I currently have a pfscore bar that will drop increments every 2 minutes (total of 16 minutes) but that really doesn't help the player understand how much time they have left at a glance - just a bar that slowly decreases.

 

2. Again, the way I have gravity set-up is a problem once jumping is implemented. It's a collision routine (player0,playfield) with the player pushing down/pushing up if in contact with the playfield. This works great until you jump where other objects, i.e. furniture made from the playfield are present (you keep moving up with each jump).

 

Those are what I'm looking at currently.


Back to your question, I'll definitely make the code available when I'm at a standstill and can't progress further. ?

 

BTW, you've done an amazing job on 1942!! That's a great port.

 

Edited by rsiddall
  • Like 2
Link to comment
Share on other sites

Made a little progress but nothing that seems to be an acceptable solution for level progression.

 

There was a suggestion by Thomas Jentzsch early on in this conversation to help reduce flicker. So I've made the player a single sprite. I think he still looks acceptable.

 

After doing that, I realized when I started creating other rooms, I would need to allow the player to move freely through an opening but still allow for gravity/push back from playfield - so walls were needed once again.

 

If using the playfield to create furniture, the walls now become a multi-color mess....UGH!!

 

With the playfield furniture creating a color problem (in addition to allowing the player to go higher while jumping), I switched back to using sprites to represent the furniture. This solves the ugly walls and higher jumps with the introduction of flicker once again.

 

BUT, with sprites I now have the problem of everything appearing exactly in the same location as the player moves from room to room.

 

UPDATED: I found an easy fix for the furniture by including the sprite I wanted into each room being drawn. So I can randomize the items I want to use i.e. fireplace in one room and not another. That's probably something that could be optimized to save space but at least I have a workable solution for now.

 

So a bit of a head-scratcher for me...

I've recorded two movies to show a couple of versions.

Edited by rsiddall
  • Like 2
Link to comment
Share on other sites

Given that it's bB, I assume you have a table somewhere that specifies playfield colors and that has some kind of direct relationship to the scanlines. Maybe that could reused as a lookup table for "gravity" collisions.

 

I assume platforms are stationary and the game works by drawing new "screens", so you'd probably want to add some sort of logic to correct the player when near the platform (maybe using a bitwise AND logic instruction?). There's really no time to loop while "falling" and make proper checks one vertical color clock at a time.

 

You could detect collisions before they happen. So, if you detect a collision at a fixed polling position below your player's avatar, you wouldn't want your game objects to "land on the ground" at different distances from the platform. Maybe you could apply logic to place the game object directly above the ground when the platform color is found, based on polling the next planned "y position" for the "falling" game object?

 

Above the player, if necessary, gamers are much more tolerant of seeing their avatar's head get pushed out of a ceiling after contact. So, you might be able to catch collisions on the bottom beforehand and check above with hardware collision, forcing the player back down after colliding with playfield. Although, using hardware collision to force the player down may not be necessary and it wouldn't work with the furniture. 

Edited by orange808
  • Like 1
Link to comment
Share on other sites

1 minute ago, orange808 said:

P.S.

Another hint:  One of the bits for the VCS colors is unused and has no effect on what you'll see on screen. At the cost of more cycles, you could isolate that bit and have a "floor" anywhere you want and any color you want.

 

I want to circle back with you once I have a chance to take everything in.

 

Appreciate the insight as I'm really just feeling my way through this without a lot of experience.

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...