Doom For Fx-9860g
#1
Posted 10 November 2007 - 02:17 PM
#2
Posted 10 November 2007 - 02:24 PM
Edit: It's a great thing you've made a 3D engine for this calculator, but I'd rather like to have a Half-Life like engine... YEAH, CALL IT CASIOSource!!!!!!!1!111eleven
And yeah, post the source code.
#3
Posted 10 November 2007 - 02:39 PM
#4
Posted 10 November 2007 - 02:43 PM
Yes, it is supposed to show up. There's no way to get perfect greyscales.I just tested it and it's really kool. Just a quick question. Is it my calc or is there suppoesed to be a white line running up the screen. It might just be because the grayscales(which look wicked btw) are to much for my crappy batteries XD
And yes, do it Half-Life like!
#5
Posted 10 November 2007 - 02:53 PM
Lol, yes, but creating a real 3D engine would be kind of hard. The engine I'm working on is quasi-3D and it's hard to do things like looking up, jumping and crouching,It's a great thing you've made a 3D engine for this calculator, but I'd rather like to have a Half-Life like engine... YEAH, CALL IT CASIOSource!!!!!!!1!111eleven
I hope that when I finish this game, the engine will be included along with Revolution-FX's graphics component.
Yeah, unfortunately, there is suppose to be a white line. It's a side effect of grayscales.I just tested it and it's really kool. Just a quick question. Is it my calc or is there suppoesed to be a white line running up the screen. It might just be because the grayscales(which look wicked btw) are to much for my crappy batteries XD.
Maybe I should just do a DOOM clone. I didn't put in any shot effects or enemies, because I don't know what enemies to have. If you guys want to help out drawing sprites, guns or special effects the specs are:It's called call of duty but it seems more like a doom game. I think you will do better just making a pure doom game anyway. The gun looked cool as well. i was fiddling around trying to see if I could shoot. But you cant :INSERT NON EXISTENT CRYING SMILEY HERE:
Sprites (enemies): 64x64 pixels - 3 colors (white, black and gray)
Guns: 16x16 pixels - 3 colors (white, black and gray)
#6
Posted 10 November 2007 - 03:08 PM
Also, what is the syntax for 32x32 and 64x64 sprites?
Edit: Never mind, I found it out, I guess...
#7
Posted 11 November 2007 - 01:20 PM
#8
Posted 11 November 2007 - 03:13 PM
I could do 4 colors I suppose. (White, light gray, dark gray and black).Um, why just 3 colours? Is it too slow for the Calc to render more colours?
Also, what is the syntax for 32x32 and 64x64 sprites?
Edit: Never mind, I found it out, I guess...
Maybe I should then switch to 4 color for the light gray.Hi everybody ! I've just tried it, and that's great, the only thing is that grey is too dark I think ...
#9
Posted 11 November 2007 - 04:56 PM
And the grey isn't so dark, it looks fine here.
#10
Posted 11 November 2007 - 06:47 PM
#11
Posted 12 November 2007 - 01:25 PM
Then there must be something wrong with your calculator. Try to change the contrast, mine's just fine.Oh no! the grey is really too dark, when you play, you sometimes cannot make difference beetween black and grey !
By the way, I wonder how is one supposed to convert a 64x64 sprite into an array of data without spending months on calculations!
#12
Posted 12 November 2007 - 01:42 PM
#13
Posted 12 November 2007 - 04:14 PM
#14
Posted 12 November 2007 - 07:28 PM
#15
Posted 13 November 2007 - 07:09 AM
EDIT:
I have a sprite for a rifle if you dont already have one. Due to my REALLY bad understanding of grayscales, it's really bad flickering. I'll just provide the two arrays because you cant actually see it with my flickers.
const unsigned char Rifleone[] = {0x00, 0x00,0x00,0x00,0x01,0x80,0x03,0xC0,0x05,0xA0,0x04,0x20,0x0C,0x30,0x14,0x28,0x14, 0x28,0x14,0x28,0x14,0x28,0x14,0x28,0x14, 0x28,0x14,0x28,0x14,0x28,0x14,0x28}; const unsigned char Rifletwo[] = {0x00, 0x00,0x00,0x00,0x01,0x80,0x03,0xC0,0x07,0xE0,0x07,0xE0,0x0F,0xF0,0x1F,0xF8,0x1F, 0xF8,0x1F,0xF8,0x1F,0xF8,0x1F,0xF8,0x1F, 0xF8,0x1F,0xF8,0x1F,0xF8,0x1F,0xF8};
#16
Posted 13 November 2007 - 06:47 PM
We need more greyscales knowledge.
#17
Posted 14 November 2007 - 04:48 AM
GrayInit(3280, 3280);For four colors (black, dark gray, light gray & white):
GrayInit(3270, 1453);
#18
Posted 14 November 2007 - 06:24 AM
#19
Posted 16 November 2007 - 04:44 PM
#20
Posted 17 November 2007 - 12:18 PM
Also, just a quick question (exams over so im back into programming ) i couldnt be bothered making new post, how can i clear and update "buffers" continously without getting flicker? AKA clear them behind the scenes like Casio VRAM... If i chuck in a
memset(&buffer1, 0, 1024); memset(&buffer2, 0, 1024);
It clears the "viewing" screen in real time creating flicker... In your 3D game theres no flicker...
#21
Posted 18 November 2007 - 02:57 AM
First of all, welcome back k3v! I'll release the code when I find the time, I'm really busy now with other projects. Maybe I could turn it into a Christmas gift project for you guys or something...Raycasting no doubt? Hehe i was wondering if you could post the source to a simple non texture-mapped raycaster as ive read up on the technique but cant find any code that i can understand Eg. the previous build of this 3D game
I actually do use memset() to clear the buffers in my 3D game. Do you have GrayInit set up properly?Also, just a quick question (exams over so im back into programming ) i couldnt be bothered making new post, how can i clear and update "buffers" continously without getting flicker? AKA clear them behind the scenes like Casio VRAM... If i chuck in a
memset(&buffer1, 0, 1024); memset(&buffer2, 0, 1024);
It clears the "viewing" screen in real time creating flicker... In your 3D game theres no flicker...
#22
Posted 18 November 2007 - 03:20 AM
Haha... okayFirst of all, welcome back k3v! I'll release the code when I find the time, I'm really busy now with other projects. Maybe I could turn it into a Christmas gift project for you guys or something...
Are you clearing the screen continiously though? Like not just when you move?I actually do use memset() to clear the buffers in my 3D game. Do you have GrayInit set up properly?
#23 Guest_casiomaster_*
Posted 30 November 2007 - 11:10 AM
I think that you could make it like counter-strik! using the terminal-fx that you made we could play in multiplayer! or even with the modem project ( it's being made in anther topic) it could be played in teams!
Give the source code ! for christmas!
#24
Posted 30 November 2007 - 12:51 PM
And so, no counter-strike.
#25
Posted 30 November 2007 - 02:34 PM
Only 25 more days until Christmas!!!
#26
Posted 30 November 2007 - 03:30 PM
#27
Posted 01 December 2007 - 12:51 AM
#28
Posted 01 December 2007 - 03:12 PM
I get moar cookies! :cookie:
...kucalc! I told you to add the cookie emoticon! XD
#29
Posted 03 December 2007 - 08:52 PM
#30
Posted 03 December 2007 - 08:56 PM
What about the game/engine's name? Are you going to keep it as "Call to Duty"?
#31
Posted 04 December 2007 - 08:36 AM
#32
Posted 12 December 2007 - 12:26 PM
Maybe I should just do a DOOM clone. I didn't put in any shot effects or enemies, because I don't know what enemies to have. If you guys want to help out drawing sprites, guns or special effects the specs are:
Sprites (enemies): 64x64 pixels - 3 colors (white, black and gray)
Guns: 16x16 pixels - 3 colors (white, black and gray)
...The hell? I don't think we really need 64x64 sized enemies. There is no image filtering, and so lots of pixels won't show up.
Also, the size! It's just too heavy for an enemy.
1. With the current storage methods, we store 8 pixel information on a byte. This means 8 bytes for 64 pixels, times 64, which make 4096 bytes.
2. An enemy doesn't just have 1 frame, it has various frames! Also, we can't just change the rotation of the sprite in the scene to make it look another way. More sprites are required, and Doom uses more than 4 different rotations of the enemy, but 4 would be enough. If we multiply: 4096 * 4 = 16384 bytes
3. No, I'm not done yet! There are animations for each rotation of the enemy, which makes it/him walk or attack/shoot. In Doom, most of the enemies use more than 1 or 2 frames for the attack sequence, and 2 or 3 frames for movement. If we used 3 frames(2 for walking, 1 for attacking), as we want a reasonable look of the enemy, we get: 16384 * 3 = 49152 bytes
4. And then, there is this: The greyscales AND the sprite mask! :shock: This means at least 2 more images for each frame! 49152 * 3 = 147456 Bytes = 144 KBytes
And no such thing as a CASIO program ever had such a space in memory.
Either you didn't explain what you want to do with the enemies, or you pretend to do some special method for them. Anyway, keep this in mind.
#33
Posted 12 December 2007 - 02:29 PM
I find that 64x64 sprites come out nicely. The textures on the walls are 64x64 sprites....The hell? I don't think we really need 64x64 sized enemies. There is no image filtering, and so lots of pixels won't show up.
Lol, you computed it wrong. (64 pixels/bits * 64 pixels/bits) / 8 bits per byte = 512 bytes per 64x64 pixel sprite. Or 8 bytes * 64 lines = 512 bytes. 512 bytes is 87.5% less than 4096 bytes.1. With the current storage methods, we store 8 pixel information on a byte. This means 8 bytes for 64 pixels, times 64, which make 4096 bytes.
#34
Posted 12 December 2007 - 05:38 PM
So the amount of bytes would be... 18KB...
The problem with using these sizes are because we can only enjoy them by full if we are really close to them. Anyways, make sure you do your best on this project. A calculator version of Doom is getting near.I find that 64x64 sprites come out nicely. The textures on the walls are 64x64 sprites.
#35
Posted 13 December 2007 - 06:25 PM
#36
Posted 14 December 2007 - 12:35 AM
#37
Posted 01 February 2008 - 03:50 AM
#38
Posted 01 February 2008 - 08:21 AM
anyways, im now downloading the game XD
looking good so far.
I cant wait to shoot that demon XD
Also, i can kinda walkthrough the demon rofl.
anyways, great, can't wait for the finished project
#39
Posted 02 February 2008 - 02:56 PM
- I really think you should use 4 colours. It'll use the same amount of picture data and will look better. Also, the demon I gave you is supposed to work on 4 colours.
- Remember that the demon doesn't always look at the player, so you might need to do some calculations in order to figure out what specific frames to use (If the demon's running away from you, you wouldn't use the frames where it's looking at the player)
- (Optional) Give us the source-code! XD ...Alright, I'm kidding. Just take your time to get something stable.
I might help you with more sprites later.
Tried it. Here's what I'd like to say about it:
- I really think you should use 4 colours. It'll use the same amount of picture data and will look better. Also, the demon I gave you is supposed to work on 4 colours.
- Remember that the demon doesn't always look at the player, so you might need to do some calculations in order to figure out what specific frames to use (If the demon's running away from you, you wouldn't use the frames where it's looking at the player)
- (Optional) Give us the source-code! XD ...Alright, I'm kidding. Just take your time to get something stable.
I might help you with more sprites later.
#40
Posted 02 February 2008 - 03:26 PM
Hehe please dont wait to long to release the raycasting engine because then it'll just get more complicated Haha, i just wanted to see the "ray" [space] "casting" part in action as ive read quite a number of tutorials and want to see some code i understand in action. Aka the angle calculations and square detection etc.
For me the Fx-9860 Lcd blurs way to much in motion to be able to differentiate between more then one shade of grey, and theres hardly enough contrast to see it static...- I really think you should use 4 colours. It'll use the same amount of picture data and will look better. Also, the demon I gave you is supposed to work on 4 colours.
Just leave it as is, its looking awesome
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users