What I got so far, and HELP! :)

[Staffan]

Hello Everyone,
Below you will find my project attached. I dont have much time to work on this, but now I have wasted half of the time I spent on this on the same problem.
When I walk up and the screen scrolls the sprites doesnt follow automaticly, so I have to update them by hand. When I change my scroll variable I also update the location of every sprite by hand like this:

Vscrolltop--;

for(int i = 1; i < NumberOfActiveSprites;i++){
spritesY++;
}

vscrolltop is an integer to keep track of the scroll. I update them on the exactly same time.

When I redraw the board it looks like this:
VDP_setVerticalScroll(PLAN_B, Vscrolltop);
SPR_update();
VDP_waitVSync();

But as you can see in the compiled rom, when you walk up, the sprites do a one pixel jump, and I tried EVERYTHING to get rid of this jump...
its very important, because otherwise I will not get the collission detection right later.

To hep with your motivation I cannot give you any money, but I'll let you have this project as open source for sgdk if I'll ever finish it.

and if anyone, wants to put my sprites variables together in a struct, thats a bonus

[attachment=0]SEGA_VSCode_Template-master.zip[/attachment]

[Stef]

This is not really a good approach to do it, too complex, not efficient and bug prone...
You need to use absolute coordinates in the whole level for your sprites and objects, these coordinates have to be stored outside the basic SGDK 'Sprite' object. Then you have your camera position defining the current visible screen position (scrolling) so when you update your sprite positions you need to subtract camera position to put them back in relative visible area coordinates

[Natsumi]

What Stef explained is what generally ALL games did and do still. But to explain in closer detail, your camera is basically the "virtual" position for everything. Sprites, planes, scrolling, everything is based on this camera, or sometimes some calculation that takes the camera as input. In your code, if you want to move everything by 1px, all your code would do is "CameraY ++;", and then rest of the engine will take care of moving the plane and the sprites automatically. Often games would recompute the sprite table and scroll buffer every single frame, regardless of whether its needed or not. I am not entirely familiar with SGDK in itself, but generally your sprites would have a coordinate system of absolute values between 0 and FFFF, and then your code would calculate the relative position to the camera, and that would be the final position in the sprite buffer sent to VDP. Of course, checking if sprite is on-screen, and not just far away from it (which would possibly cause VDP to display it on-screen anyway). Plane itself is also rather easy - Just negate the camera x-pos, and y-pos you can just copy assuming your code works so that lower y values mean the camera is higher.

Building such a system may not be the easy way out, but it prevents you from creating an unmaintainable mess of code that will break like a twig if you do something unexpected. Using a camera will ensure your sprites never get desynced or updated incorrectly, and same for the plane. It also means you dont have to iterate through each sprite to update its position and you can do accurate collision detection even if your object is at the other end of the virtual game map. Of course, there are cases where you may actually want to use a static camera and just update positions, I've done it in the past, but it makes it greatly difficult to build a game with a free-moving dynamic feel. In my case, I intentionally limited the "camera" to only move certain amount per certain number of frames, so I did not have to worry about desync.

[Stef]

Oh yeah sorry for not having bring more details about it, in fact lately i think i have received about 4 times this question about how implement correct scrolling for long map (and so had replied it 4 times :p). I definitely need to do a proper example with the 'sprite' sample embedded in SGDK for that

[Natsumi]

Well honestly it is not exactly rocket science once you understand the concept =P

[Miquel]

What others said is really the proper way to do it.

About the jump you mentioned, I can't see it on screen with the rom you provided, but any way, this is probably due you do a similar process:
1) Copy sprites on VRAM
2) Update sprites and scroll position
3) Scroll is updated at Vblank inside VDP (doesn't matter when you write it)

As you see, steeps 1 and 2 need to be exchanged to everything be synchronized.

One more thing, the code you provided is too much hard coded, you only allow scroll of 1 pixel per frame. Try to put everything into a function and parameterize it. Also sprites on the HUD, menu, ... and others shouldn't be involved in this operation (a flag could be usefull).

[Staffan]

Hi!
Thanx for all answers, well its only one pixel high.

I have now tried and do it with a camera. Its the same bug, but perhaps its something with the emulator? What kind of emulator did you use, when you didnt see it?

I now have the positions of sprites in a separe array, so at least it shoudnt be any problems with collission detection later, but its still visible a pixel error in kega fusion at least.

asStefSaid.zip

withCamerasortOf

(130.28 KiB) Downloaded 6961 times

[Stef]

I think you update the vscroll too soon, just do it right after waitVSync() so it will happen during vblank, at same time the sprites will be sent to the VDP... It's important sprites coordinates are in sync with your vscroll value.

Also you are doing some sprite updates / vscroll change directly in the joypad event handle (vint) and putting code in .h file which isn't really recommended

[Staffan]

Hello again,
yes for small projects like this I use a lot of global varables, because I think its the fastest way to develop. Might be a little ashamed to say now that I work as a programmer

Dont really see the point in being able to scroll faster than 1 pixel for this game. The main sprite controls the scroll, so therefore its in the joypad event.
In this simple game, its all about the main sprite....

I wish I could do good stuff like create a struct for my sprite variables. But I have forgotten the syntax and pointer stuff. It might take two hours to check it, but when you have such little time its better to just code so you understand it yourself. See progress and stay motivated.

[Staffan]

That did the trick. Putting scroll after vsync.
Tjanx alot!

[Miquel]

Dont really see the point in being able to scroll faster than 1 pixel for this game.

I don't know the specifics of you game, but one of the big reason that games becomes boring is repetitiveness, both for gamers and developer. Is like playing the same song over and over for months, you will end hating it.

To avoid this situation the easiest way is to make variations of what already you have.

[Staffan]

The adventure of Lolo was actually a single screen game, but the BEST one. (Next to bubble n Bubble).
Now when im porting it, I use 3x3 characters instead of original 2*2, its doesnt fit a single screen anymore.

I might even steal the original level design, because I hte to design levels.

[Miquel]

Makes sense: NES doesn't have enought memory to do a modifiable map much larger than an screen. But instead this games changes powers every level, for example.