This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Hot_Dog
Pages: 1 ... 25 26 [27] 28 29 ... 194
391
« on: October 30, 2011, 09:17:01 pm »
how is this going?
Actually, this would probably be a good time for a progress update. I just fixed the bug where enemies were disappering into walls, a problem that existed in the original Gemini. At least I think I fixed it. Also, I fixed a bug where health bars were popping up even without an enemy on-screen. Now to continue work on saving games 
392
« on: October 30, 2011, 05:58:58 pm »
My monochrome artwork. Everything fits on a TI calculator screen(I prefer 96*64). If you want me to make titlescreens or cutscenes: just ask I also make sprites
(Ow I also work with grayscale sometimes)
I'll look you up  I have cutscenes planned for my game
393
« on: October 29, 2011, 07:29:33 pm »
In the game Gemini (and thus Elimination as well), every enemy has an X position and a Y position. I'm pretty sure that the X position and Y position are governed by the left side of the enemy when you are facing it. In other words, if an enemy is at X = 1200 and Y = 1300 in one possible situation, this is the left of the enemy, and the middle of the enemy will be at approximately X = 1215 and Y = 1315 in some cases.
Also, every enemy position takes two bytes. If the X position is stored in HL, H will contain the tile from a row of 32 tiles, and L will contain the location to the nearest 1/256 of that particular tile. If the Y position is stored in HL, H will contain the tile from a COLUMN of 32 tiles, and so on.
Collision detection in Gemini checks the X and Y position to see if the tile an enemy is on is occupied by a wall. Register B contains the tile number out of the 32 tiles in a row, and register C contains the tile number of 32 tiles in a column. If C * 32 + B points to a tile that is occupied by a wall, the enemy is told not to move to that direction, and a new direction is calculated.
So here's my problem. Registers B and C will, like I said at the top, pertain to the LEFT of the sprite. So the left side of the sprite never, ever runs into a wall. However, the right side often does. Considering the code below, what's a good way to fix that?
EDIT: Part of my problem is the enemy always faces toward you, no matter at what angle you are facing in the map.
objectsEnemyCalm:
; --------------------- ;
; Update enemy movement ;
; --------------------- ;
ld hl, (object)
ld de, 14
add hl, de
ld a, (hl) ;This is how many units the enemy will move in the current direction
or a
jr nz, objectsEnemyMove
dec hl
ld a, r
srl a
srl a
ld (hl), a ;Store a direction, from 1 - 32
inc hl
ld a, r
srl a
srl a
ld (hl), a ;Store how many units the enemy will move in the direction
objectsEnemyMove:
dec (hl)
dec hl
ld a, (hl)
; Get trigs
ld hl, movtbl
ld b, 0
ld c, a
add hl, bc
ld e, (hl)
ld c, 8
add hl, bc
ld d, (hl)
; Speed depends on enemy
ld hl, (object)
ld a, (hl)
and %00111111
or a
jr z, objectsHandgunSpeed
dec a
jr z, objectsShotgunSpeed
dec a
jr z, objectsChaingunSpeed
; Plasma-rifle enemy, move swiftly
jp objectsSpeedDone
objectsHandgunSpeed:
sra d
sra e
jp objectsSpeedDone
objectsShotgunSpeed:
sra d
sra e
jp objectsSpeedDone
objectsChaingunSpeed:
sra d
sra e
sra d
sra e
objectsSpeedDone:
; New X
ld bc, (objectX)
ld h, 0
ld l, d
ld a, l
and $80
jr z, objectsPosCos
dec h
objectsPosCos:
add hl, bc
ld (ox), hl
; New Y
ld bc, (objectY)
ld h, 0
ld l, e
ld a, l
and $80
jr z, objectsPosSin
dec h
objectsPosSin:
add hl, bc
ld (oy), hl
ld a, (ox + 1)
ld b, a
ld a, (oy + 1)
ld c, a
call checkLevel
or a
jr nz, objectsEnemyWalkingWall
;;;CODE IS MISSING FROM HERE. IT JUST SAYS "YES, THERE'S NO WALL, MOVE THE ENEMY."
objectsEnemyWalkingWall:
; Enemy was walking into a wall, new direction
ld hl, (object)
ld bc, 14
add hl, bc
xor a
ld (hl), a
jp objectsEnemyLocation
;;;;CODE IS MISSING FROM HERE, IT'S IRRELEVANT CODE.
; ========================== ;
; Check cell of level (b, c) ;
; ========================== ;
checkLevel:
ld a, b
ld b, 0
sla c
sla c
sla c
sla c
rl b
sla c
rl b
ld hl, level
add hl, bc
ld b, 0
ld c, a
add hl, bc
ld a, (hl)
ret
movtbl:
.db 0, 6, 12, 17, 22, 26, 29, 31, 32, 31, 29, 26, 22, 17, 12, 6
.db 0, -6, -12, -17, -22, -26, -29, -31, -32, -31, -29, -26, -22, -17, -12, -6
.db 0, 6, 12, 17, 22, 26, 29, 31,
394
« on: October 24, 2011, 07:14:35 pm »
Some of level 4! New features:
* Herm Injection!
* Better map revealing: more is revealed from exploring, and doors have a symbol different from walls
* Health Bars! (I did my best to make some health bars higher on the screen than others to help with distinguishing them, but it's not perfect) By the way, these health bars have been extremely helpful in distinguishing enemies from other objects.
* Armor now reduces, rather than eliminates, damage taken, except for really weak enemies. Armor will take 1/2 of the damage rounded up, and health will take the other half rounded down.
395
« on: October 24, 2011, 03:34:57 pm »
You know, we always talk about how NOP is a useless instruction, but actually, ld a, a etc. are the only useless instructions on the z80. NOP DOES have its purposes
396
« on: October 23, 2011, 06:25:28 pm »
I understand your point Hot Dog, it's true. But some pressure is also needed. Like, if the programmer doesn't feel like adding a very major feature to the game and everybody loves it we should help him (coding, spriting, etc.) and say "That would completely change the game and make it really awesome". It may not work, and it should not be abused if the programmer really doesn't want to, but just a bit of pressure may be crucial
That's also a good point. We just don't want the programmer to feel like the game will be terrible without the requested feature.
397
« on: October 23, 2011, 03:08:43 pm »
Ben_G and boot2490, the small health pack now gives 10 health, and the big one gives 25 health. Ben_G, I will adjust the arboretum level you gave me so that you don't have to correct it yourself.
398
« on: October 23, 2011, 02:44:07 pm »
As a suggestion, could the rocket launcher be somehow "flattened" a bit more? IMHO it seems like it's pointing upwards in that screenshot.
Hmmm...I agree with you there. But I honestly can't think of what to do to change it--my 3d pixel-art skills are not the best.
399
« on: October 23, 2011, 12:26:23 pm »
We have some clear winners! It was a close call, and I can't bear to part with any one of the 5 high-voted power-ups, so I'll incorporate all five somehow. (I think I know of an easy way to do so)
So the A190 Pressurizer, the Herm Injection, the Map, the Case of Cylinders and the Disintegration Suit will all be in the game.
I've now included a new poll: Should the Map power-up reveal secrets?
400
« on: October 23, 2011, 11:44:32 am »
I wanted to offer more advice to help Omnimaga with being a friendly community. A person writing a game or an application for calculators is not getting paid to do so, he or she is doing it for fun. But a person has only so many hours in the day for "fun" as opposed to "work," so only so much can go into the game. For this reason, the programmer has to choose what to put into a game and what to remove. In my case, I choose what will be fun to program and what will be boring to program, even if the boring part will sweeten the look and feel of the game. (There can be a boring portion that will take only 2 hours, and a fun portion that will take 10, yet I will still choose the fun part over the boring part  ) But with sufficient peer pressure, the programmer will feel obliged to add a feature because "everyone wants it." At this point, the list of what goes into the game gets larger and larger, until the programmer is either unable to finish the game or loses interest in the game. Does this mean we shouldn't offer suggestions? No. Does this mean we should say that a game with numerous bugs is absolutely outstanding? No. What it does mean is we need to be content when a programmer says "That's a good idea, and I understand how you feel, but I don't want to do that." If there's a really cool side-scrolling space shooter game, and the programmer doesn't feel like going through the trouble of adding triple lasers that fire in different directions, we need to understand that it's the programmer's game, and it will never get done if he feels too pressured to continue making it.
401
« on: October 23, 2011, 11:21:33 am »
Um, so it doesn't fire a rocket, just an invisible explody beam?
It's supposed to represent a rocket. The imagination can do wonders
402
« on: October 23, 2011, 12:54:56 am »
Hmm now that I look again at it, they sayt eh helion transforms like the viking. Does it means it becomes an air unit? Because if that's the case, I hope the upgrade is not too early in the game, otherwise defending helion harrass as zerg will be next to impossible.
It means it the hellion transforms into something different. The viking transforms between air and ground, so it's either one or the other. But it doesn't cost the viking anything once the upgrade is researched. So the hellion is either fast or slow/heavy, but it's not both at once. And I also like the new hydra-speed thing
403
« on: October 23, 2011, 12:44:46 am »
I haven't been lazy! But to keep you guys entertained, here's a snippet of the rocket launcher, which I've been working on (and am still working on). I was tempted to program rockets as objects that could move around the map, but in the end I decided to keep things simple.
By the way, the rocket launcher is probably going to be a little more unforgiving than it is in DOOM. Meaning, you have to be pretty far away to avoid being hurt. However, you will less likely injure yourself from a close target than you will from a closER target.
404
« on: October 22, 2011, 11:27:51 pm »
Now that would be cool. Wouldn't you go past them when you used it, though?
That's part of the problem. Personally, though, I would enjoy simply running through them and knowing that I had knocked the stuffing out of them
Pages: 1 ... 25 26 [27] 28 29 ... 194
|
Show Posts