RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
I've updated the pdf in the first post to include instructions for the new Img2Code.
-
2
-
-
Titlescreen Kernel docs now updated. Thanks Jeff!
-
Pong
in batari Basic
A few things I see at first glance...
- colup0 and colup1 should be COLUP0 and COLUP1
- you were missing a "goto mainloop" at the end
- if statements don't work over multiple lines in bB
COLUPF = 14 player0x = 30 : player0y = 44:player1x = 130 : player1y = 44 missile0height = 0 missile0x = 80 missile0y = 44 player0: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 end player1: %00000000 %00011000 %00011000 %00011000 %00011000 %00011000 %00000000 end playfield: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ ................................ XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX end mainloop COLUP0 = 14 COLUP1 = 14 drawscreen if joy0up then player0y=player0y+2 if joy0down then player0y=player0y-2 if joy1up then player1y=player1y+2 if joy1down then player1y=player1y-2 if collision (missile0,player0) then AUDV0=15:AUDC0=4:AUDF0=13:musictimer=30 if collision (missile0,player1) then AUDV0=15:AUDC0=4:AUDF0=13:musictimer=30 goto mainloop
I don't have the opportunity to try it out, but I think that should work.
- colup0 and colup1 should be COLUP0 and COLUP1
-
Great point Philsan. I've just updated my copy of the docs with it.
When I get to writing up about Jeff's changes to Img2Code, in the next day or so, I'll attach the updated copy to the first post.
-
That's pretty good. I'm not sure why, but the way he moves looks familiar... almost Lode Runner-esque.
I'll do up the Sprite files for ya a little later. 
The conversion would be much appreciated!
I agree that he seems kinda familiar, but I think it's just that non-bobbing floaty run cycles were pretty common back in the day.
Given that this is "help yourself" art, it's probably a good thing that he looks generic; nobody will likely notice if he turns up in a few games.
-
An 8x8 run cycle. This time there's no head bob - it was a sacrificed for more detail on the body and a more proportioned head.
To me it looks more like a generic video game runner. Also, the standing frame could easily be converted into a up/down walk cycle by just shortening alternating arms and legs to give them motion.
-
1
-
-
Thanks Jeff!
When I get a chance I'll try it out and update my docs. Without the cut and pasting, it will be a lot faster creating titlescreens!
-
1
-
-
My 2 cents... if a new homebrew resorts to using the second joystick, it should also optionally support the C button on sega genesis pads. C could be used to toggle the menu mode on and off.
-
That would save a variable. Can you do that for different numbers besides 4? If so, would it be hard for a new user to figure out? If it's difficult to figure out, maybe I could put a chart on the bB page. And is there a way to slow it down without wasting a variable?
The example I posted is adapted from something jrok gave me. For the animation in my program to run at the right speed, I have to wait for the loop to go around 7 times before I can add one to Frame_Counter.
You can use other numbers, but the delay and the number of frames need to be powers of 2.
jrok's code is more flexible because it works with arbitrary numbers, but as you point out it uses additional variables. In practise I don't find using powers of 2 very constraining.
The other downside of the second part of my example, is that my "frame animation" code runs every frame instead of just an update on the key frames. Not the biggest deal to me either, since sprite updates don't use a lot of cycles.
On second thought, it might be easier to understand if the division happens first...
rem for a 4 frame animation that changes frames every 8/60ths of a second... temp1=(frame/8)&%00000011 on temp1 gosub drawguyf1 drawguyf2 drawguyf3 drawguyf4
-
I do things a bit differently for my code that doesn't run each frame...
frame=frame+1 rem to do something every 4 frames... temp1=frame&%00000011 rem temp1 will be zero once ever 4 frames if temp1=0 then gosub dothingevery4frames rem or to update a 4 frame animation every 4 frames temp1=(frame&%00001100)/4 on temp1 gosub drawguyf1 drawguyf2 drawguyf3 drawguyf4
-
There's no corporate will.
Your slim client would still need a GPU, CPU, memory. Even if they they all have lesser specs than the main console, it means the company now has a second console to design, manufacture and support.
I'd rather see the return of split screen gaming. It used to be an expected feature of the last gen, but now only select titles have it.
A pity, since now we have bigger TVs and faster consoles to support it.
-
Thanks yuppicide! I agree that the 30hz doesn't add anything.
Given the comments on the thread I pulled the flicker code. I'll need to think of more traditional ways to do the embellishments, like a ball flickered for both ship's thrust, etc.
I learned what doesn't work, so at least it wasn't a waste of time.
Thanks for your inputs, all. They've helped me greatly!
-
This artical from the LA Times is about a month old and I am surprised that it didn't get mentioned on Atariage...
Be surprised no longer!
-
The reason their are no patches is simply it's impossible with the current hardware design. when you play a game everything (even the home menu) runs off the disk.
http://wiibrew.org/wiki/IOSThe "Home" menu you see when you press the Home button is part of the game, it is not provided by the running IOS or the System Menu. To put it simply, the game does not run "on top of" the system menu. When a game is launched the system menu is closed and the game is started, and when the game calls to return to the system menu, the game closes and the system menu is restarted.
It's not impossible for that reason. The game still uses an IOS held on the nand for library functions - just not the same one the system menu uses. If a new game needs a new IOS, it gets delivered in an update to the system before the game will play.
If it modifying the IOS a game uses was impossible, there wouldn't be USB loaders. They use a patched IOS that replaces the disc sector reading routines with their own routines.
However, it is impractical to patch games via an IOS update. To change an IOS, Nintendo would need to QA test all of the games that use that IOS, including 3rd party games.
We're also unlikely to see patches for Wiimotion plus for existing games because it's not a simple matter - the old wiimote motion sensing API doesn't have the same resolution/info as the new wiimotion plus API. Each game would need to be custom patched to use the new API and do something sensible with it.
That kind of rework isn't going to fund itself, and there's no profit motive to do it.
-
Yup, it looks to be there too!
-
[edit - nevermind. Covered in post 21]
-
I grabbed the zip file from this post and unzipped it into the bB includes directory.
Then I edited the file "superchipheader.asm" and added the line include "superchip.h" under include "vcs.h".
theloon's example compiled and ran for me then, even with the lo/hi byte symbols.
-
1
-
-
Problem is that I don't know what you are trying to do. Are you trying to use const like it's def or macro?
He's adapting an example from SeaGtGruff, and it should work as he's written it. The < and > symbols are supposed to return the lo and hi bytes of the address r000.
In my environment I'm completely missing the definitions for r000, r001, ..., and w000, w001, etc.
I think theloon has the same problem.
-
All I know is when I run it and move the ship around at any speed, I feel like I'm going to puke.
Ok, so it is the color-movement thing then. I'll save the effect for my Splatterhouse port then.
Thanks for suffering for my art!
-
1
-
-
Instead of trying to mix 2 colors, you could have one color for the round ship and the other color for the middle and fire out the back. You'd go back and trim out any red that isn't for the back or middle. Then it would look good and not make people sick to their stomachs.
I might not be understanding right - do you mean draw the ship body in one frame and the fire in the other?
In that case the body of the ship would flicker against the black background, which would make the flicker even more obvious.
Is the effect really "sick to their stomachs" bad? In my stella window the body of the ship doesn't look very different when phosphorus is turned on or off, at least when the ship is standing still.
-
Both binaries just look like flickery sprites to me. Would be good for energy missiles or lasers. Not so good if the eyes have to focus on them for long periods of time. Is there a way to interleave colors instead of flickering them?
If by interleave you mean something like the flickerblinds (like the 96-pixel wide bitmaps in the TSK) then that's possible, but it will introduce combing artifacts with moving sprites.
Thanks for looking at the binary and making suggestions guys. If anybody has more, keep 'em coming. I want to think about this before I tear out the flicker code and go with mono sprites.
-
When moving, both versions kind of remind me of looking at an old 3D movie without the blue and red glasses on. Is there any other trick you can do to keep them lined up?
I'm tapped. Maybe I'll remove the center window detail and just have the ship bodies and thrust flames, though they'll still do that fringe effect.
It's interesting that the 30 hz version does that. (it does that for me too)
If you move it frame by frame in stella you'll see that both frames always alternate on top of each other, even when the ship is in motion.
I guess our brains are confused when they see the color change but the intermediate ship frame hasn't travelled to where our brain expects it to be.
-
I started working on a WIP that uses flickering for color effects, but I'm a bit torn on the approach, so I was looking for opinions.
The game uses rotating sprites, so the usual line based color changes aren't really an option.
Instead I went with a flicker-based color approach... the sprite alternates between 2 colors each frame. The main body of the sprite is in both frames, so it winds up being a mix of the 2 colors. Details that are only in frame 1 or frame 2 show up flickered in that frame's color.
If the explanation is confusing, it's basically the technique I used in the yoshi color-by-flicker example in the Titlescreen Kernel thread.
Here's the WIP...
The approach has some artifacts when the ship is in motion. The main artifact is the details "float" a bit at certain speeds. Is these objectionable? Is the "pro" of the color worth the "con" of the floating?
I tried out a variation where the ship position gets updates every other frame, to minimize the artifacts...
But I think the loss of smoothness might not be worth it.
-
How about using your program code for sprite data like Yars Revenge did?
I should correct myself before someone else does - yars did this with a playfield register - but otherwise it's a similar effect.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
The Titlescreen Kernel
in batari Basic
Posted
I'm the first to admit that creating a titlescreen isn't a simple matter, so don't take the issues you are having personally. You're having a problem, so let's just work through it.
My initial guess is that maybe you've trimmed off a column from the data instead of a row. But its just a guess. Did you try the data as-is, without the trimming?
It will make things easier if you attach the files involved (source image, the image assembly, and your .bas) to a post here or a PM to me.
I'd expect display glitches from too much data - not for the game to crash. So maybe something else is happening.
I'll take a look at the documentation figure in question and see what I can do. Thanks for bringing it up!