Quick question on Renegade/Target Renegade graphics

[remax]

Do you plan to release a movie after that? 

That would be a shame to write such a big scenario and not use it to it's full possibility !

[Joseman]

Do you plan to release a movie after that? 

That would be a shame to write such a big scenario and not use it to it's full possibility !

Actually could be a trilogy with extended versions if the plot continues expanding that quickly 

[Gryzor]

I'll get the BluRay version then

[sigh]

The first level Boss moves have now been completed. It's the heavy type and I will be using that template for the female version with a few adjustments. I'm now moving on to the weapon demo which I will be starting tomorrow. It's going to take a while but I'm hoping to have it done in around 2 weeks.

[sigh]

Okay; there are a total of eight weapons in the game.

Two weapon animations have been completed so far, one of them being the most complex of all the weapons.
I have another complicated weapon which I will be starting this afternoon and when it's done, the rest should be very easy.

Here is the female enemy design.



Also, I have now figured out the ending that I want for the story. 

[ukmarkh]

Don't effing rush it... Take your time, when it's finished I'd love to give it a review 

[sigh]

Story so far:

I have finished the weapon attack animations, but I need to animate the hit reactions for the other characters. Started some of the hit reactions for the normal enemies, but some still need to be done for the main characters and the boss. It's been far more complicated than I first thought.

What happens after:

After finishing the weapon hit reactions, I'll be creating another presentation piece for the programmers on how the weapons actually work. This will be easier to create compared to the first demo, where I hadn't yet animated the hit reactions in which I had to create in order to get it working for demostration purposes.

[sigh]

Hello everyone,

It's nearly 2 months since my last post on this so here is an update.

All the gameplay fighting mechanics including all the weapons have been done and sent to the programmers. I will be given information on memory space as there are a lot of interesting but complex moves which is very likely going to need much planning on the programmers part, but will be fantastic if we manage to pull it off.

I'm pretty please with the mechanics so far.

I was originally going to start the female enemy template which will be tracing the female player animations with a different head, but I might start looking into creating a demo of the musical atmosphere I would like to hear in the game, as this will take up some memory too.

[Swainy]

So looking forward to this.

[Gryzor]

Thanks for the update mate, please stay on course

[sigh]

Hi guys and gals,

An update as it's been a rather long time since I posted.

Work on this from my side (things are progressing on programming)will be resuming when I get back to the UK as I'm currently away.

I've only managed to do some rough planning on the second level and some more research on music. I'm sstill wondering how they managed to achieve the sound effects and music on Renegade playing at the same time, without any noticable interruptions on either of the channels. There must be some clever trick that they are using to avoid having the sound effects cut into the music? Or maybe the music is really only on 2 channels and not 3? The music sounds really rich and full so maybe I'm just not listening hard enough to determine how it's done.

I'm still thinking that the drum beat and fighting sound effects should be on the same channel, as you wouldn't notice the change in sound too much, as both would share a similar rhythym.

Also - my laptop speakers aren't that great.

[Gryzor]

Thanks for the update man...

[ukmarkh]

Would be nice to get a full run down like you gave a year or so ago as to the progress and percentage left until the game is finished.
I have so many questions, have you decided on the final name of this game? Who's doing the music? Who's involved on the programming front, and have you consulted with the original programmers of Renegade to work out the music and sound effects issue? They hang around a lot on Facebook these days.
I'm really exited about this potential game, it looks like you've thought of everything, but at the same time considered the CPC's limitations.
Can't wait for your next update. 

[arnoldemu]

Would be nice to get a full run down like you gave a year or so ago as to the progress and percentage left until the game is finished.
I have so many questions, have you decided on the final name of this game? Who's doing the music? Who's involved on the programming front, and have you consulted with the original programmers of Renegade to work out the music and sound effects issue? They hang around a lot on Facebook these days.
I'm really exited about this potential game, it looks like you've thought of everything, but at the same time considered the CPC's limitations.
Can't wait for your next update.

I am coding this game.

I am targetting a 128KB machine with a disc drive.

About 80% of ram is currently used; this is with 2 player characters Lots of cpu time is used, I need to do optimisations.

A rundown of the current implementation which is subject to change (depending on ram constraints etc):
- 2 16KB screens are used for double buffering
- screen is hardware scrolled using R3 and R5 to make smooth vertical and horizontal scrolling
- there is a panel at the bottom that uses another area of ram.
- screen is split using demo techniques and there is a gap between play area and panel (same as prehistorik 2).
- main area is mode 0, panel is mode 1.
- graphic frames are stored in extra ram, along with level tile graphics and level tile indices.
- sprites are flipped at runtime; so only half the sprites are stored. I am using a method similar to renegade, storing top half and lower half seperately and a minimum area for each sprite and still the ram space is very tight.
- most of the engine is made in assembler; with the ai being implemented in c while I develop it.

Using c gives me better and quicker iteration and allows me to easily spot optimisations.

I am currently testing the game using arnold wip and a real gx4000 (The game is meant for disc and 128kb, but with slight code modifications i have made a cartridge for 64kb gx4000 and I am using that to test all the timings and things are accurate). Writing the AI is taking time and it's the most important part to make it fun.

The problems I can see so far:
1. not enough ram
2. not enough cpu time

I don't worry about sfx/music. I don't know why they chose to split them in renegade.

I am choosing not to release demos because I am expecting things to change, so any demo may not be a true representation of the final game.

I would be interested in talking to the programmers of Renegade; more to find out why they chose to do things a specific way. I do have an idea why, but it would be good to talk and confirm it with them.

[Puresox]

Don't wanna kYA. But brilliant piece of explaining , the ins and outs . Specially for people like me who have an interest in trying to  understand the process in programming, but only from casual respect. My talents lay elsewhere , but love to get more of a grip on how you guys do it.

[arnoldemu]

I'll give a little more detail of the current engine. Remember it can change!

Two screens:
Screen 1 @ &c000-&ffff
Screen 2 @ &8000-&ffff

This leaves &4000-&ffff open for expansion RAM (when 128K disc) or putting lower rom here to simulate 128K using lowest 8 pages of cartridge.

&0700-&3fff, main code + code to manage banks.
&100-&1ff is table for masking sprites. (mode 0, 15 colours, pen 0 transparent)
&200-&2ff is for shift table so sprites can be done pixel by pixel.
&300-&3ff is for reversing pixels for drawing sprites in any direction.
&400-&4ff is for "white" table so sprites can flash white when hit
&500-&6ff is for screen table to help me to calculate screen addresses from x,y coords.

Current code is 11K! This is engine + C code compiled + some debug code.

top part of screen is 32 crtc chars wide and 18 crtc chars tall.

panel is 32 crtc chars wide and 6 crtc chars tall.
panel is located at &4000 currently and organised like a normal screen. Approx 3K used but not continuous. I could put music player here.

Map uses 256 tiles. Tiles are 16 lines tall and 4 pixels wide. 8K for tile graphics. Map is 32x8x12.
Approx 3K/4K (tile indices). It uses page "&c7". Sprites use &c4,&c5,&c6.

Problem is that data must be continuous and not span banks, so I have some open areas which will be awkward to fill because the remaining will be small.

My sprite routines do not allow pixels to cross banks because it would be too complex to do that.

Stack is at &4000 and grows down.

128k may not be enough.

The game *will* multi-load, I don't have enough free ram to hold everything at the same time.

[TFM]

Interesting how 'nature' forces coevoluton. My engine for 128 KB is not so different, except that I have the 2nd screen at 0 and the block 8000-C000 as common block (main prg, stack, im2 table etc).


128 KB is not very much indeed.


Keep the good work going, I'm looking forward to a release one day. 

[sigh]

Hi guys and gals,

Sorry for the slow reply and updates. I was out of the country for 3 months and got back around a month ago and have been trying to finish one of my very old projects from aeons ago, as well as intensly looking for a job in order to make the tax man go away!

I haven't been able to progress much on the music/sfx or the female characters template at the moment, but rest assured I will be back onto them as soon as I sort myself out. I will need to try and get the female template done for sure and give the programmers more info, on the second stage layout as I'm also giving a helping hand to 2 other people on their own projects.

I will update with a break down sheet hopefully around the first week of August, in regards to the important milestones left to do in regards to the sprite templates.

[cosa_nostra-6128]

I hope you can finish everything with 128k, to avoid having to make more memory, and function in a 6128 standard, good luck

[TFM]

Keep it going @sigh - a super big project like this surely takes it's time! Take a break, but please never stop! 

[ukmarkh]

What's wrong with flip screen as used in Renegade / Target Renegade and Gryzor. I for one wouldn't care, advantages are a bigger screen, no need for double buffering and less ram needed. Scrolling in these types of games is overrated, bringing the fight is the most important thing for gaming enthusiasts. Just my two pence worth...

[arnoldemu]

What's wrong with flip screen as used in Renegade / Target Renegade and Gryzor. I for one wouldn't care, advantages are a bigger screen, no need for double buffering and less ram needed. Scrolling in these types of games is overrated, bringing the fight is the most important thing for gaming enthusiasts. Just my two pence worth...

Nothing is wrong with flip screen. I chose to investigate scrolling first.

I totally understand where you coming from here: having flip screen can help you to concentrate on the action and can give finer control.

I will consider flip screen. There are a few things that can and may change before release.

I am also considering  joystick control with single fire, joystick control with two fire buttons, or joystick control and keyboard like renegade on cpc.

For me the AI is very important and the control needs to be tight and responsive and intuative to how the moves are triggered.

[sigh]

What's wrong with flip screen as used in Renegade / Target Renegade and Gryzor. I for one wouldn't care, advantages are a bigger screen, no need for double buffering and less ram needed. Scrolling in these types of games is overrated, bringing the fight is the most important thing for gaming enthusiasts. Just my two pence worth...

As stated by arnoldemu, there is nothing wrong with flip screen.

I would like to have scrolling as the results that arnoldemu has investigated on so far has been fantastic. Also - I prefer scrolling in beat em up games rather than flip screen as it makes the gameplay feel smoother in my experience.*

Another important thing is that arnoldemu, Munchausen and myself have been approaching some interesting gameplay styles, scrolling methods, animation techniques, new ways to tackle AI etc. We're finding new ways to do things where knowledge can be passed onto other people for future CPC projects. So if arnoldemu creates an optimized scrolling method on the CPC for people to use, then that can only be a good thing.

*There's a lot of graphic, sound effects and AI considerations in the game, so if we cant get scrolling then we'll just have to flip it:D

[Gryzor]

I think I prefer scroll, but gameplay comes first. And a bigger playing area means better gameplay, too.


In my mind the only real drawback of flipscreen appears when you don't check the enemies/player positions carefully and you end up smashing your face onto an opponent when changing screens.

[ukmarkh]

Really looking forward to this, hopefully it will see the light of day in 2016, fingers crossed. Any updates would be swell ;-)