Main Menu

Donkey Kong Country 2 WIP

Started by LemonWizard, April 21, 2015, 11:17:54 PM

Previous topic - Next topic

LemonWizard

Hello once again everyone. It's been a while hasn't it?
And wouldn't you know it.. it's been a long time but I'm still working on my dkc2 game engine.

You can refer to the old post about it in the showcase for pics and old demos.
Not much has changed, but here's a new video showing some of it:

https://www.youtube.com/watch?v=3hcgfVXZVoU



MODEDIT: use the youtube in square bracket pairs to parse videos into a post.


It runs much better on the pc I use now.
Also, some animal buddies in the works (Sort of)

and another update video here:

https://www.youtube.com/watch?v=jEq9i4wmKWU

These aren't really edited.

What these videos demonstrate are some larger changes.
You can see squitter here.
You can also see Rhambi's been haphazardly implemented.

Multiple placement of tiles.
Better physics for the blast barrels (still need work)
Integration of sound effects for objects that came as a result of making functions handle objects.
One internal change you won't notice is that game objects are mostly objects now with the exception of a few items.
The zingers, balloons (you won't see those in the video), coins (same thing), few other things. All added.
The balloons, bananas, coins, and blast barrels have the sound effects.

There's more. I've even began a new engine which should be backwards compatible with this one.
The new engine is actually going to be based on what I learned making this one.
The new engine features multiple cameras and a better more organized code base but
the new engine is graphically limited at the moment and only has some of the support code
that would be needed.

Here's some of the code from the new engine:

Initialization:

world_width=500
world_height=32
camera_x=0;
camera_y=0;
current_level=1
global max_cameras=10
global backdrop_city=loadnewfximage("Level_Bgs\City.png")
global backdrop_room1=loadnewfximage("Level_Bgs\HexOne.png")
global backdrop_room2=loadnewfximage("Level_Bgs\HexTwo.png")
global tile=loadnewfximage("Tiles\Base.png")

type cameras
camera_x
camera_y
camera_id
backdrop
id
endtype

type backdrops
x1
y1
scrollspeed
backdropimage(1)
id
drawmode
endtype

type particle
image
id
x1
y1
max_height
max_width
max_speed
amount
endtype




last_camera_id=0;

dim game_cameras(max_cameras) as cameras
game_cameras(1).camera_x=0
game_cameras(1).camera_y=0
game_cameras(1).backdrop=1
game_cameras(1).id=1
dim game_backdrops(10) as backdrops
game_backdrops(1).x1=0
game_backdrops(1).y1=0
game_backdrops(1).scrollspeed=0
//game_backdrops(1).backdropimage(1)=backdrop_city;
game_backdrops(1).drawmode=0
game_backdrops(1).backdropimage(1)=newfximage(640, 480)
copyimage backdrop_city, game_backdrops(1).backdropimage(1)
game_backdrops(2).backdropimage(1)=newfximage(640, 480)
copyimage backdrop_room1, game_backdrops(2).backdropimage(1)
game_backdrops(2).x1=0
game_backdrops(2).y1=0
game_backdrops(2).drawmode=0
game_backdrops(3).backdropimage(1)=newfximage(640, 480)
copyimage backdrop_room2, game_backdrops(3).backdropimage(1)



dim game_particles(100) as particle



dim background_map(world_width, world_height)

//fill the first level up


for tempx=1 to world_width
for tempy=1 to world_height

if tempy=>30 then background_map(tempx, tempy)=1


next tempy
next tempx




Then we have support functions. Again alot more organized than my old engine codebase!



//This will draw the image to the screen instead of the world
function drawtoscreen(image, screenx, screeny, drawmode)

endfunction


//This will draw the image to the world , using camera offsets
function drawtoworld(image, worldx, worldy, drawmode, camerax, cameray)

endfunction

function remove_particle_generator(id, game_particles().particle)


endfunction

function add_particle_generator(image, max_height, max_width, max_speed, amount, game_particles().particle, x1, y1)


endfunction id

function draw_hud()

endfunction


function render_camera(camera_id, game_cameras().cameras, game_backdrops().backdrops)

camera_index=get_camera_by_id(camera_id, game_cameras().cameras)
backdrop_index=get_camera_backdrop(camera_id, game_cameras().cameras)
camera_x=game_cameras(camera_id).camera_x
camera_y=game_cameras(camera_id).camera_y
drawimage game_backdrops(backdrop_index).backdropimage(1), game_backdrops(backdrop_index).x1, game_backdrops(backdrop_index).y1, game_backdrops(backdrop_index).drawmode



endfunction

function get_camera_by_id(id, game_cameras().cameras)

for temp=1 to max_cameras
if game_cameras(temp).id=id
camera_index=temp
exitfor

endif

next temp

endfunction camera_index

function get_camera_backdrop(camera_id, game_cameras().cameras)

camera_index=get_camera_by_id(camera_id, game_cameras().cameras)
backdrop_index=game_cameras(camera_index).backdrop


endfunction backdrop_index

function change_camera_backdrop(camera_id, game_cameras().cameras, newbackdropindex)

camera_index=get_camera_by_id(camera_id, game_cameras().cameras)
game_cameras(camera_index).backdrop=newbackdropindex

endfunction

function draw_tiles(camera_x, camera_y)

//Get the tile indexes
ScrollAmountX=Roundup(camera_x/32)
ScrollAmountY=Roundup(camera_y/32)

for tempx=1 to 20
for tempy=1 to 15



screenx=(tempx-1)*32 + ScrollAmountX
screeny=(tempy-1(*32 + ScrollAmountY

if map(tempx, tempy)=1 then drawtoscreen(tile, screenx, screeny, 0)


next tempy
next tempx

endfunction


And finally, now instead of having a good 500 lines of code to get the camera to render I have this. Note the camera backdrops are forced to change in this to test camera rendering with backdrops:


current_backdrop=2
do


print "It's working"


drawimage game_backdrops(1).backdropimage(1), 0, 0, 0

current_backdrop=current_backdrop+1
if current_backdrop>3 then current_backdrop=2

change_camera_backdrop(1, game_cameras().cameras, current_backdrop)

//Draw this camera
render_camera(1, game_cameras().cameras, game_backdrops().backdrops)

sync
cls rgb(0,0,0)

loop



And that's basically it. pretty good right?

Anyways, I've been further analyzing the dkc2 game and I'm strongly considering learning some snes asm and figuring out
how the actual game originally did things.
I've seen the code before but I couldn't understand some of it.
The idea if I can get some of the original code re built in playbasic will be to write support functions
that mimick exactly how the game did things with the exception of hardware level rendering.

That said there'll be special graphical effects I need to learn to mimick.
Take for example The level Glimmer's Galleon, as shown here:



Then there's things like the distortion of the water as seen in the photo from the level slime climb:


So yeah a new engine is definitely going to be called for.
I'm still going to be coding most of this in playbasic and I'll most likely try to work
on the two projects side by side both engines, and as I go I'll be creating as much cross-compatibility between the two of them as I can.
Then we get to see which engine performs more efficiently when it's all set and done.

Can a well coded object management engine out do a sort of linear hybrid between the two?

Todolist:
Build new engine with future intention of keeping things cross-compatible between the two.
Import old assets into new engine eventually.
Give new engine scripting capabilities, particle capabilities, and all that from the outset.
Make water a thing. (no seriously I have to make it a thing. lol it isn't a thing in the old engine)
Better level editing in the new engine or revise how it's done in the old one.
Make levels cross-compatible between both engine versions. (You may think this is alot of work but it's not)
Make both engines aware of which version the level is intended for. Make the other engine able to drop features
that aren't supported from level files without mis reading level files.
Test dynamic cameras in new engines and test how quickly a scene can be switched.

Both engines only draw "tiles" as they are on screen.
Enemies and other "objects" current collision routine in the old engine needs revision.
Most important add support for collision or terrain collision regions.
That way multiple layers of terrain (flat curved smooth) terrain can be achieved in the new engine. Old engine probably won't support this.
Proper object system that is efficient and doesn't require recursive loops through lists. (oh god how can I have like over 200 different object types that collide with eachother? )
Considering just having the above as a per frame feature.
Or maybe even prioritize objects to check first.
For speed purposes, I'm considering having game-objects in the new engine load into memory as they are read by position.
In this case I'll need to give objects a flag option which makes them stay loaded.
I might even need to give them a flag to respawn if not destroyed.
Check, check and check...
and in three years I probably still won't be done this if I procrastinate >.<

Nah I'll be done it. by then. For sure.
It's coming along alot faster now and I'm alot better at coding now to than I used to be. I mean ALOT better 0_0
Hopefully that to do list won't be too overwhelming.
I'll plan to have scripting in the engine ( I swear) early on so I don't have to figure out how it fits seamlessly
with all the other already-fitting pieces.
I'm treating the new game engine as pieces which will hopefully be able to be mixed together or modified in a modular way.
A camera should be able to contain game-objects.
I should be able to do cutscenes this way to.

This month's goal:
Get both diddie and dixie in there as playable characters and implement all of the full mechanics involved in the level Rickety Race.
It can be seen here->https://www.youtube.com/watch?v=sF_o5EsaCt0