[V9990] Q&A Official Thread

Страница 4/19
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 11:19

MrSpock wrote:
Kai Magazine wrote:

I do not quite understand what you mean, and probably you did not understand me either, because it is not a nightmare at all, as a matter of fact it is quite simple.

I think that what Manuel is saying is that if you detect a bug in the common code for all stage*.bas, then you have to correct all the stage*.bas and test them all again. That's the "nightmare" of code duplication.

Ah, yes, if that is what manuel meant, then indeed this is a handycap.
Anyway once I find a bug in one of the .bas, I leave the modified lines on the screen, then I load another stage, I press enter over those lines, then save, load the next stage, enter, save...
I can modify the bug on all the stages in a matter of 1 or 2 minutes.
Depending on the bug (wether it affects the modifications on the other stages or not) I do no need to test them all since I know the program structure very well.

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 11:33

hit9918 wrote:

are you using an objects rack.

	on objectid[i] gosub 1000,1100,1200...
	

1000 'this is a bullet
1010 x[i] = x[i] + dx[i]. ... return
...
1100 'this is a turtle
1120 some other move code ... return

how many bytes does a room need

	data 3,90,100	;create a type 3 ID on (90,100)
	data 4,80,80
	data -1		;-1 is end

in the end this could be in vram and no more consume RAM.

Something similar, but not quite that.
Offcourse I use dimensioned arrays for all the objects, and I use a variable to define what kind of object is that, and it's size and behavior.
Usually I use "same size" sprites so I use the same variable that defines the kind of object to define the coordinate of the source vram area in which the sprites of that object are stored, so I do not have to define the size of each frame or each object (with the exeption of bullets, explosions, knives and boxes) but I usually simplify it very much by using the "kind of object) variable to modify the size easily.
All this is designed to save RAM space, not Vram, since the RAM is the most scarce resource on turbobasic.

For example: on LOM, the main character's software sprites are stored on the invisible area of page 0, and all the frames are 16*32 pixels.
Enemy type 1 on page 1, enemy tipe 2 on page 2, enemy type 3 on page 3.
So if the "kind of object" variable is 0 to 3, it automatically copys the correct sprite from the correct page to show the correct object:
Copy(0,0)-(15,31),object type variable to (x(i),y(i),workpage

Then I control the frames with another variable. Frames go from 0 to 7 (8 frames pr direction) so I only have to add this:

Copy(frame variable(i),0)-(framevariable(i)+15,31),object type variable to (x(i),y(i)),workpage

So, one single line handles all the character's sprites with 2 variables, and I do not need to store frame data on arrays.

I do have to do execeptions with bullets and explosions, but that is all.
The pickable items in the game are not objects, but tiles, so no memory or cpu is used in them whatsoever.

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 11:38

I forgot to mention, I control the direction with a variable, and I add that variable to that copy line. That variable is 0 or 128 depending on the direction. If the direction is Right, the variable is 0 so it will show the 8 first frames starting from the left. if the variable is 128 it will use the next 8 frames which are the same, but inverted...
So:

Copy(frame variable(i) + directionvariable,0)-(framevariable(i)+15+directionvariable,31),object type variable to (x(i),y(i)),workpage

That is the full formula to show all the 4 character's sprites with just 3 variables.
I did not find a more "memory friendly" formula than 1 small line of code and 3 variables.

By AxelStone

Prophet (2674)

Аватар пользователя AxelStone

03-03-2016, 13:30

MrSpock wrote:
Kai Magazine wrote:

I do not quite understand what you mean, and probably you did not understand me either, because it is not a nightmare at all, as a matter of fact it is quite simple.

I think that what Manuel is saying is that if you detect a bug in the common code for all stage*.bas, then you have to correct all the stage*.bas and test them all again. That's the "nightmare" of code duplication.

In BASIC you run out of memory too soon, so you have 2 options:
1) Make your game simpler.
2) Make several engines with some variations (different enemies, objects, etc)

You decide what do you prefer Smile

By anonymous

incognito ergo sum (109)

Аватар пользователя anonymous

03-03-2016, 14:42

AxelStone wrote:
MrSpock wrote:

I think that what Manuel is saying is that if you detect a bug in the common code for all stage*.bas, then you have to correct all the stage*.bas and test them all again. That's the "nightmare" of code duplication.

In BASIC you run out of memory too soon, so you have 2 options:
1) Make your game simpler.
2) Make several engines with some variations (different enemies, objects, etc)

That's true, but it does not change what I said.

AxelStone wrote:

You decide what do you prefer Smile

As always, there is a third option: do not use BASIC. ;-)

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 15:37

This third option has proven to leave projects in vaporware way too many times.
I am looking for a way to achieve results quickly and easily, so the chances to finish a project are higher.
The third option takes too long and it seems to be the problem with most projects beyond msx1 small games.

By syn

Paragon (1920)

Аватар пользователя syn

03-03-2016, 15:59

Kai Magazine wrote:

The third option takes too long and it seems to be the problem with most projects beyond msx1 small games.

I disagree. The coding language itself isnt the problem. The downfall is content, as in creating original graphics, music, gamedesign etc etc. At least from what I have seen, most "big" projects that get delayed/forgotten is due to lack of content, while the coding itself is mostly done. Look at Xtazy, the gaming engine was somewhat complete (gfx, music, hitdetection etc). Two working levels. Imo It is content creation that makes ppl lose their motivation often (because they prefer to code or whatever)

The reason people keep making small msx1 games (other than nostalgia/preferring msx1) is that they somehow think msx2/2+/tr/gfx9000 games should be epic/big/megaprojects, while instead they could have just made a small puzzlegame for those platforms.

By Josb

Master (196)

Аватар пользователя Josb

03-03-2016, 16:20

Kai Magazine wrote:

This third option has proven to leave projects in vaporware way too many times.
I am looking for a way to achieve results quickly and easily, so the chances to finish a project are higher.
The third option takes too long and it seems to be the problem with most projects beyond msx1 small games.

I partially agree with you because I think it would be good to have some tools to make easier develop with asm. For example, a pre-built code just to use or graphic libraries or what else.

Anyway, I'm keen on MSX-BASIC code Smile

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 16:33

Josb wrote:
Kai Magazine wrote:

This third option has proven to leave projects in vaporware way too many times.
I am looking for a way to achieve results quickly and easily, so the chances to finish a project are higher.
The third option takes too long and it seems to be the problem with most projects beyond msx1 small games.

I partially agree with you because I think it would be good to have some tools to make easier develop with asm. For example, a pre-built code just to use or graphic libraries or what else.

Anyway, I'm keen on MSX-BASIC code Smile

Then I have good news for you:
ASM graphic libraries to use GFX9k on ASM and even on C:

https://www.teambomba.net/gfx9klib.html

Here are also several useful tools as well.

Enjoy!

By Kai Magazine

Paragon (1303)

Аватар пользователя Kai Magazine

03-03-2016, 16:39

By the way, regarding those libraries I just linked before:
If anyone would be kind enough to assamble them in such a way I can bload them from basic and use them with DEFUSR, we could have acces to the GFX9000 graphic commands from Basic, Gbasic and even from Gbasic+regular turbo basic, which would be a huge step fordward towards programming easily for z80 + gfx9k.

Any takers? Smile

Страница 4/19
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9